The Misleader

A QA who often reports bugs inaccurately, leading the developer down the wrong path as they attempt to reproduce and fix the problem.

  • Can mutate into: “The Alarmist” QA
  • Dangerous when coupled with: “The Statistician” Project Manager
  • Likelihood of fixing: High
  • Danger to project: High


Reporting a bug requires the following:

  1. The ability to spot that there is, in fact, a bug
  2. The ability to determine the steps to reproduce the bug
  3. The ability to describe the bug holistically, often pointing to root cause
  4. The ability to clearly articulate the steps to reproduce

At any one of these steps, it is possible for the bug report to mislead the developer, causing the developer to waste time:

  • If there is no bug, the developer wastes time attempting to find a problem that does not exist
  • If the bug cannot actually be reproduced, the developer wastes time attempting to reproduce it
  • If the bug is not described properly, the developer can waste time looking for too specific or too broad root cause
  • If the steps to reproduce are difficult to follow, or inaccurate, the developer wastes time attempting to interpret them, or may declare their is no bug when one still exists

Occasionally misleading a developer will happen as a result of humans making mistakes, and this is to be expected. However, the Misleader QA does this habitually, creating a significant amount of frustration among the developers. If this situation is allowed to continue, the QA tester will eventually lose credibility with the developers, and legitimate bugs they find will go unfixed as developers reject their bug reports as a matter of course.


The Misleader QA tester is often good at finding bugs; they are just poor at documenting them. Therefore, training them how to report a bug properly is worth the effort.

One of the more effective techniques to help the Misleader improve is to have them observe a developer using one of their bug reports to diagnose an issue. This is as simple as sitting them next to a developer who has received one of their bug reports, and have them quietly observe (without intervention) what the developer goes through. This normally leads to a healthy conversation about how to better report a bug that both the Developer and QA appreciate.

Leave a Reply