Dogfooding comes from the phrase first used in 1988 by a Microsoft manager Paul Maritz who wanted to improve a product and emailed his colleague the following message: “We are going to have to eat our own dogfood and test the product ourselves.” Microsoft created an internal server called dogfood and then sent the product out to staff for testing. It means using the software you make, often in beta form, to figure out new ways for improving it for your users.
Empathy and understanding of the user’s perspective are key for designing great experiences. By increasing the internal usage of the company products, tech companies (and many others) help team members to walk in the user’s shoes and build empathy for them. Real-world testing before or right after the release helps both end-users and product management. Here are a few examples to show you the benefits of dogfooding:
At Deviniti, we like testing our internal products. We use dogfooding as a method for bug tracking, developing the products, and gathering feedback on the UX much faster than from the commercial customers. Now we have over 250 people in 10 departments, so we adopt apps a team creates in selected teams who work on other projects. After implementing the solution in production systems, we release the tools to other teams and departments. Sometimes, we even publish them as publicly available commercial products. In this article, we decided to share how we use this approach to perfect our requirements and test management tools for Jira. Read on to find out how we develop our apps and why dogfooding is a smart idea for product development.
This app is dedicated to developers, business analysts, testers, and test managers. It combines all aspects of software development, including requirements, tests, and bug reporting, on one platform. Moreover, the app is easy to use thanks to great UX, and the onboarding process is lightning-fast to enable testers to start working as quickly as possible.
We use Requirements and Test Management for Jira Cloud in two teams: the one who creates the product itself and the overall Apps Quality Assurance team. The product team owns the requirements section by arranging them per feature, which gives the newcomers a quick insight into the product to help them learn faster. The issue statuses give a useful hint to the support team about the current requirements’ fulfillment — here nested folders and emojis help to arrange the structure a lot. Having the requirements structure at hand, they can communicate the current plans to the customers without having to additionally consult with the product team.
Then both teams use the Test Case module to describe all the Test Cases according to Page Object standards. Then they create Test Plans — for example, regression tests, new features, automated tests. After this, the Test Execution structure grouped by version gives an overview of the executions performed previously and immediately see problematic releases. Next, they categorize Defects by release to enable bug monitoring. Among the interesting features, there are emoji for marking objects (for example, the tests intended for automation and the ones that are already in automation), which are perfect for visual learners. On the QA team, each project has the app installed — that’s where the test documentation is stored, created, and expanded. Then the issue links from all across Jira are a great feature as well — support tickets can be linked with bugs and requirements, which makes both sides’ jobs easier.
Thanks to the internal use of this app, we immediately see what we’re missing, what the problems are, and quickly spot bugs. This rule is helpful for us: every error in our application must be assigned to a Test Case, even if it’s loosely related. We do this to ensure that none of the bugs are lost.
Jarosław Solecki, RTM for Jira Product Owner
The QA team prepares dogfood feedback for the RTM team. On a Confluence page, the testers leave their remarks and possible improvements. There’s also an ongoing discussion on a dedicated Slack channel about the new improvements in the app’s design and development. By adding the feedback from the support team about the use of the app by the customers afterward, this makes for a diversely developed backlog.
It’s a flexible test management app for Jira that puts requirements testing, test case management, and test reporting right on the Jira issue view. The app can be configured to match any testing process, offering teams extraordinary flexibility. TestFLO for Jira also offers full traceability from requirements through test cases to bugs and easy integration with any existing requirements management process. We use this app in two service departments and by the product team itself.
The first department is Atlassian Services, which implements and improves business and IT processes in the Atlassian stack. These projects are often complicated and require excellent quality assurance to hand over the solutions to our customers. Our project teams use TestFLO to guarantee that the configuration and custom-developed Jira apps are up to the agreed standards. Thanks to the app’s unmatched flexibility, they can configure it to reflect the specificity of each client’s Jira instance. The app supports our Atlassian Experts in delivering an excellent quality of configurations so that our clients can benefit from stable solutions.
Another department that uses TestFLO is our Application Development department. These teams develop web and mobile applications, mainly in Java and associated frameworks, as well as Android and iOS apps. Each client has their requirements regarding test management — while some use waterfall, others love Agile. The teams can adjust to any process thanks to TestFLO’s configurability. They can align the tool to any expectations and deliver clear reports from the tests, proving to our clients that the applications have been thoroughly tested. Sometimes the customer installs TestFLO on their side, and sometimes we integrate our Jira instance with the customers’ using Issue Sync for Jira to work on the user stories together. The stories are then linked with test cases so that the client can generate end-to-end requirements traceability reports.
Last but not least, there’s the product development team itself. To ensure that the app is tested and stable before releasing it to the Atlassian Marketplace, they use TestFLO to test its new versions. The process leverages user stories in Scrum, where the stories and test cases are displayed on a sprint board. In one Jira project, the team develops and follows the entire implementation and release process, and in another one, they plan and execute tests. The automated tests run in Bamboo, and the results are sent back to Jira so that the team can track the progress of automatic and manual tests together, having the entire picture of the process in front of their eyes. The team has also used the app’s Filter Result Panel in the release management process. Thanks to aggregating all types of reports related to a given version on the issue view, they can see all the Jira issues related to a release directly in the issue representing the release itself. This way, the product manager can track the release’s progress throughout the entire development cycle, developers can control how much work is left to estimate, the technical writers can assess the stage of the work and decide when to proceed with the initial outline of the documentation, and the support team informs the clients about the version status.
Since we’re using TestFLO in-house, we empathize better with our customers and can quickly assess the value of feature suggestions that they send to us through our support channel.
Radosław Cichocki, TestFLO for Jira Product Owner
Based on the requirements prepared by the Product Owner, the testers describe the test paths to cover them. They create linked Test Case Templates in the Test Repository, reuse tests from the Precondition repository, and have an additional workflow condition provided by the app that is used to avoid executing Test Cases when the Test Plan isn’t ready yet.
The dogfooding approach demonstrates product usefulness and usability for the market early on. The fresh perspective of someone unfamiliar with the product helps us to avoid the trap of creating a solution to a problem that doesn’t exist and allows catching errors and problems much earlier. The first feedback and feature requests don’t come from the product managers but from the users themselves who are part of our organization. Getting to know our own products inside out also means that we can deliver better support to both internal and external users. The practice also helps us to build a collaborative environment that breaks down the departmental silo. For us, dogfooding cuts down on development and support costs and helps to save the team lots of time by addressing issues that could delay product release. The users across different teams at Deviniti get the tools that solve their problems at work, so we mutually optimize our effectiveness as well. Promoting product awareness and knowledge across the entire organization can help to build enthusiasm and even love for the products within the company.
As an Atlassian Platinum Solution Enterprise Partner and a Platinum Marketplace Partner, we’ve been working hard on bringing requirements and test management to Jira Software. With our expert services and dedicated apps on the Atlassian Marketplace, we’ve enhanced the overall quality of work comfort and customer service in over 5000 companies around the globe.
If you want to learn more, make sure to check out other articles available on the Atlassian Community:
Dzmitry Hryb _Deviniti_
The manager’s daily activities include a list of challenges to reach high levels of efficiency for their teams. Part of these challenges is related to how to deal with the worklog systems sin...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event