A QA who accuses the developers of not testing their work whenever they find a bug.
- Can mutate into: “The Alarmist” QA
- Dangerous when coupled with: “The Statistician” Project Manager
- Likelihood of fixing: High
- Danger to project: Low
Every bug theoretically could have been found and fixed by a developer before QA found and reported it. This leads some QA testers to take each bug found as further evidence that the developers are not testing their work sufficiently. This is an undeniable fact, empowering the Blamer QA tester to be even more vocal with their disparaging assessment of the development team.
The Blamer QA tester is ultimately caustic to the morale of the project. Rather than helping to improve the quality of the product, their focus is on proving that the development team is not doing their job. Every bug, rather than being taken at face value, is added to the pile of evidence that developers have developed an overreliance on QA to find bugs that they should have found instead.
Sadly, the Blamer QA is normally made by the organization through a fairly predictable process:
- A critical bug is found in production
- The QA tester is blamed for missing the bug
This happens far too often, and it is therefore understandable that the QA tester would defend themselves using an argument that is irrefutable.
Before any effort should be made to fix the Blamer, the organization must first stop blaming QA for missing bugs that find their way into production. Whomever is doing the blaming must be coached into a more productive method of helping the entire development organization improve its ability to deliver quality software, rather than just singling out QA.
Once the organization has stopped blaming QA for missing bugs, a Blamer QA can be addressed by offering them a shift in perspective, as well as a shift in attitude:
The shift in perspective is that developers are only human, and they are prone to making mistakes. To compensate for their human tendency to make mistakes, the QA organization acts as a guard against their mistakes affecting customers. Additionally, due to the tedious nature of software development, it is all too easy for a developer not to see the forest for the trees, as they are so focused on solving a particular problem that they forget to test something seemingly obvious.
The shift in attitude is simply one of teamwork, and that teammates should not blame each other for making mistakes, and instead should help them recover from their mistakes for the benefit of the team. In the role of QA, it is especially important to establish a partnership with the development team for the sake of the project, and smooth bug identification, bug reporting, and bug fixing life cycle is critical to ensure the quality of a product.