I used to work at a company with no QA team. Before every release, we would host a bug hunt where all engineers, data analysts, and product managers would sit together around a table and go through the new features, looking for unexpected behaviors.
At K Health, we have a great QA team, but while working on a large, complicated feature, I felt like this practice could help us with a few problems we were facing. After hosting the first bug hunt, I realized this event offers far more benefits than anticipated. It quickly became an important tool in our pre-release tool-box - one that gives our engineers great confidence in releasing their features to production.
1: Make Large Projects More Agile-Like
Working on a large project can have many downsides. You can easily find yourself handling a waterfall-like process, struggling to even identify the project’s status due to the unexpected costs of integration and inability to test the parts you do have integrated.
Breaking down a big project into stand-alone, testable milestones makes all the difference, even if those phases aren’t deployable and won’t make it to production before project completion.
The benefit of a bug hunt here is two-fold:
First, when trying to break a project up, it helps to think in terms of what could be a bug hunt subject. Doing this allows us to keep the process agile, even when features are not released continuously.
Second, it provides that opportunity for celebrating achievements. For most developers, celebrating the release of their work or seeing it used by users is a great source of motivation, but there aren’t many opportunities for this on a long project. A bug hunt is an opportunity to showcase a milestone of the project, test it, and celebrate its completion instead.
2: Develop a Sense of Ownership
Even with a strong QA team, the quality of a feature is always ultimately in the hands of the engineers building it. The QA team can provide resources and expertise, but it is the development team’s best interest to validate their product’s quality before it is released. After all, they are the ones who will be alerted if any incidents happen once the feature is in production.
Bug hunts led by engineers help to develop this sense of ownership and dissuade the idea that an engineer’s job is done once their feature is handed off to QA for testing.
3: Enhance Quality & Increase Motivation For bug solving
No one knows a feature as well as the engineer who wrote it, which is why an engineer-led bug hunt can help to find eventhe trickiest and most elusive bugs.
I also found that engineers are far more motivated to solve bugs that they discovered or experienced themselves, than bugs reported by the QA team or others. Having engineers actively participate enhances their accountability and engages them in the release process.
4: Experience the product as users
Engineers don’t always get to complete full flows in the product from a user’s perspective. Bug hunts are an opportunity to use your product as a user — preferably on real devices and not through a simulator or in a dev environment. This experience enhances developers’ familiarity with our app and it’s features, and occasionally raises interesting insights or ideas.
5: Engage other Teams In the Development process
A bug hunt shouldn’t be limited to engineers. In fact, I discovered it’s a rather easy opportunity to unite people across different teams working on a feature and make them all a part of the release process. If designers, researchers, or other teams at your company are not as involved in the release process as you’d like them to be, this is a great opportunity for them to take part, experience progress made, and contribute.
All this at the small price of an hour of your time! What a great deal. If you are convinced and can’t wait to get started, check out this article.
