“Good catch!” – I was told by my teammate after finding a nasty bug while testing before releasing the product to production. At the start of my testing career, I was somehow proud of those moments – yet it always came with a bit of sadness. Why? Well, we all have heard how “testers don’t win popularity contests”: when you find an issue, it may stop the release of the product, it may lower the excitement of the team. The pat on the back with a “good catch” is more of a rarity. With more experience and getting involved way earlier in the software development cycle, I no longer feel proud of detecting bugs, I feel sad that we did not… prevent it. Then, I dig deep.
Preventing bugs is difficult to comprehend: how can we measure something that did not take place? Aristotle has said, “Quality is not an act, it’s a habit.” This is my mantra when it comes to quality practices: testing is an activity that some of us do better than others, but even if we do a lot of testing it does not equal better quality. Quality comes from daily habits and practices that can help us to have fewer bugs in the end. Bugs that get away are often the symptoms of a missing habit. Bugs are a chance for us to re-evaluate our ways of work and what we could improve. We have to learn from our mistakes so we don’t repeat them. So, how to dig deeper into the discovered bugs?
Step 1: Where could we have caught this bug earliest?
Ouch, we found a bug in production. Not great, but let’s take a look not only at how to fix it fastest, but also decide what kind of issue it is. There are two main types of where bugs lay: unspecified/misunderstood requirements or missing checks in the development. When you read a bug, ask yourself how we could have prevented it. What about planning more thoroughly and adding edge cases to the requirements as well? Or maybe that specific case was in the requirements, but we missed implementing an automated check for it. Afterwards, we may have missed it in exploratory testing as well. Spot the earliest slot where it could have been found and use it as a lesson for upcoming work.
Step 2: Why, oh why, didn’t we spot it in this stage?
Answering the question from step 1 may be extremely helpful, but there is another dimension to that: the why. There are many possible reasons why we may have not included the automated check or missed a requirement.
The 5 Why’s technique can be useful to take a look at some of the issues.
Take a regression example: we find that a new functionality we implemented affected the older one and there’s a bug now.
- Why? We did not know that this new feature would affect the older one, too.
- Why? There was no automated check for that.
- Why? The developer could not add a unit test.
- Why? We had to deliver fast and it would have taken too much time to do that.
- Why? The code logic is too complex to refactor easily.
Here we discovered a possible technical debt problem that could hit us in the future if not tackled.
Step 3: What can we do to prevent this issue from happening again?
Once we have dug deeper to understand the real cause of a bug with steps 1 and 2, we can decide on what action item is worth taking. Maybe it is introducing process helpers like the definition of ready to remind us of what should be in the requirements, or collecting and tackling development issues: be it tech debt or even spreading better testing mindset within the team by pair testing more.
Next time you find a bug: dig deep
These three tips of digging deeper are going to equip you on this extremely interesting journey of trying to build high-quality products from the start. A bug is a blessing in disguise that helps us discover the real systematic issues we may be facing in the development process. Use a chance to dig deeper once you discover an issue, you may be surprised that there’s actually a completely different problem that caused the bug to appear than you first thought.
Know our Super Writer:
Lina Zubyte
Lina Zubyte is a passionate Quality Advocate who loves to ask questions, test, collaborate with diverse departments, and investigate issues. Lina has worked in companies of different sizes (large multinational companies and startups), moved between countries for work, and has had to adapt quickly to get out of her comfort zone. She shares her writings on all things quality at https://qualitybits.tech, and you can find her on Twitter as @buggylina.
