Why Do QA Engineers Love Finding Bugs but I Personally Hate It
Why do QA Engineers love finding bugs?
Becuase it is very rewarding. No one would say it out loud, but it feels like you are the smartest person in the room. It often means that you’ve found something that the Product Manager (PM) with 10 years of experience missed or defined incorrectly. Or it might mean that the smug developer, with a Computer Science degree, forgot to handle a requirement or simply wrote “bad” code. Also, it might mean that, thanks to you, a blunder in front of a customer was prevented.
After the bugs are squashed and the feature is released, the PM comes to you and says: “Great job!” The developer comes to you and says: “Amazing work finding all these bugs! I would have never found them trying to test on my own.”
What’s not to love about finding bugs?
I remember having such feelings when I started as a QA Engineer. My primary goal was to uncover as many bugs as possible. The extent of my success in this role was informally gauged by the number of bugs I could detect.
When I started at HiredScore, in 2019, where I am now a Quality Domain Owner, I was still trying to find as many bugs as possible. I was proud about finding the ones that escaped the few unit tests and manual sanity testing of the developers. But then, my direct manager at the time, Dennis Nerush, started asking me some challenging questions and raised some interesting points. He would ask/say:
- How could we have prevented this bug?
- How come we didn’t catch this in the planning meeting, when the PM presented the requirements?
- How can we prevent this bug from happening again?
- The time you spend on manually finding and reporting bugs is time you didn’t spend working on writing automated tests and production monitors that would find bugs for you.
I began to question whether finding bugs was the best use of my time and skills…
Manual testing involves a lot of waste:
- Automation is significantly faster than manual actions performed by humans, such as clicking and navigating in the UI or running API and DB queries manually.
- The manual testing phase, particularly when conducted by someone other than the developer, starts relatively late in the feature lifecycle
- Thorough, time-consuming, reporting of each discovered bug is crucial to ensure that someone else, the developer, can read the ticket and have all the information they need to quickly reproduce and debug.
- Bugs sometimes mean that the tester is blocked from testing other scenarios.
- After each fix cycle, the tester needs to run all the test scenarios again since the fix might have caused a regression.
- More often than not, the back and forth cycle between a tester and a developer happens multiple times for a single task. This means multiple context switches and frustration for two people.
In contrast, automated tests, despite their upfront costs, provide long-term value through improved efficiency, consistency, and test coverage. They enable quick feedback, cost-effectiveness, and reusability, resulting in more more advantages than manual testing, especially in repetitive and regression testing scenarios.
In addition to test automation, a QA, or Quality Domain Owner, as we call it here at HiredScore, can do much more when they don’t waste time on manual testing. For example:
- Improve the test infrastructure, including reporting, better error messages, improved test robustness and reliability, and more.
- Make sure there are better logs and better production monitoring.
- Help your team understand the state of quality in their domain and make sure it is being improved over time.
- Help improve processes in your team and the R&D org that will help everyone deliver faster and with more confidence.
- Advocate for a culture of continuous learning from mistakes (using postmortems and retrospectives)
Nowadays, I hate it when we find bugs. I say we because, in my team, quality is owned by the entire team. Developers write test plans and test their features thoroughly. I barely do manual testing these days. When we find a bug, we think:
- How come we missed this? Where did we go wrong?
- What do we need to improve for next time?
- What automated tests do we need to add?
It wasn’t easy getting there, and it’s still not perfect. We knew at the beginning that there would likely be a reduction in quality, but we also knew in the long-term it would pay off, and it surely has.
A few of the efforts we tried and recommend:
- Going cold turkey, or in other words decide that, from now on, tickets don’t go through a QA tester by default.
- Developers write a detailed test plan before starting to code in each ticket. Use ChatGPT (or similar) to assist with designing test cases.
- The QA — or at least one other person — reviews the test plan.
- Do a hands-on test plan writing training session for developers.
- Invest more heavily in automated tests, including UI automation, unit tests, and production monitors. Use ChatGPT (or similar) to assist with writing and improving automated tests.
- For larger features, conduct a “bug bash” session with the entire squad participating in testing. It’s a fun team activity and it helps train everyone in testing practices.
Long story short, the joy of finding bugs as a QA Engineer has evolved into a pursuit of preventing them from surfacing in the first place. My journey from manual tester to a Quality Domain Owner has been a testament to the fact that, while change is challenging, it is also rewarding (and necessary). By shifting the focus to preventive measures, automated testing, and team-wide quality ownership, we’ve managed to create an environment where bugs are no longer triumphs, but opportunities for improvement. Today, the success of quality assurance isn’t measured by the number of bugs found, but by the robustness of our systems and the resilience of our processes. The evolution of my role is a testament to the belief that, in the end, quality is not the sole responsibility of a single role, but the collective effort of an entire team.
