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.
Examples of dogfooding
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:
- Facebook Android app. In 2012, Facebook’s Android app was criticized for being slow and buggy. It also lacked many features people could use on the web version of Facebook. What did Facebook do? The company internally blocked its own website and encouraged its employees to switch from Android phones to experience the app just like their users. Then Facebook released an Android app that offered a greatly improved user experience.
- Gmail. Dogfooding is a common practice at Google, which often develops products the internal team can use internally (as well as externally). One of the best examples of this practice is Gmail, one of the most popular email tools in the world.
- Lyft. The on-demand ride-hailing app Lyft requires all of its corporate employees to spend at least four hours as a Lyft driver every quarter (that includes the executives as well!). This is how Lyft gets to improve its features and solve problems before they start affecting more users.
Dogfooding at Deviniti
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.
Requirements & Test Management for Jira
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 & 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.
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.
TestFLO for Jira
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 Applications 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.
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.
If you’d like to learn more about test management in Jira Software, check out this video tutorial series on our YouTube.
Also, make sure to check out other articles available on the Deviniti blog: