A Tester 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
Problem
Reporting a bug requires the following:
- The ability to spot that there is, in fact, a bug
- The ability to determine the steps to reproduce the bug
- The ability to describe the bug holistically, often pointing to root cause
- 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.
Solution
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.
I will point out that some bugs may not be reproducible (or understood how to reproduce), but may still be worth reporting.
“I’m not sure what is happening, but a few times I’ve logged in as a low-level user and found myself in the admin panel” is worth passing on for investigation, even if the exact steps aren’t yet known.
The *may* in the “May still be worth reporting” can be very difficult to determine. On one hand, what if there was some temporary system configuration that showed a bug momentarily (e.g., someone restarting a system dependence in the middle of testing…it happens)? On the other hand, what if a non-deterministic yet high severity bug shows itself only once in a blue-moon, but even seeing it once is enough for us to track down the potential root cause so that (say) under production load something that was non-deterministic in testing trends towards determinism in production (e.g. 2% of our users are reporting this problem during peak loads). This is a difficult call, as every bug costs money to investigate.
FWIW, when I encounter situations like this I take it on a case-by-case basis, usually when someone in QA says, “I saw something weird but I only saw it once, do you think I should report it?” If it was a high severity bug, I most likely would say to report it and state clearly that it is not deterministic (i.e., it can’t be reproduced by following a simple series of steps). If it was a low severity, I might not want to take a developer off of whatever task they are on to investigate it. My approach – for better or for worse – is to treat each situation individually after a conversation with the analyst who found it.
So wait. Are we including under this the QA people that just don’t document what they did? Pretty much leaving out which QA site they tested against, what the input data was, what the result was, when they ran their test, etc. That’s one of the big killers I’ve run into QA and the closest I’ve seen to that person is under this heading but that doesn’t seem to be quite the right fit.
Yes, I would say “The Misleader” is the closest fit to someone who doesn’t document what they did to produce a bug. The key word in the description of the archetype is “inaccurately” – and inaccuracy can mean too little information (the situation I believe you are describing) or the wrong information (what most people may think of as “misleading”). In either case, the developer has to waste time trying to figure out exactly what the bug is the QA is reporting, and not documenting steps to reproduce is one of many ways a Misleader can waste a developer’s time.
I’d say a better title would be “soon to be unemployed”
What is this person actually doing then? They are not a QA analyst, they are dispassionate and a waste of time and space. They need to be removed and replaced by someone who actually cares about what they are doing and the mission.
Too many people are in software that have no business being where they are, and it such a shame.
Sadly commonly they are employed because so long as they’re reporting bugs their team leads are happy. That can happen when the relations sour between the entire QA and entire dev team. There becomes a us vs them mentality. Therefore they will not get rid of a QA staff who the devs complain about, and instead keep them on because “look at all the bugs they’re reporting! Clearly those devs are in the wrong!” Its especially frustrating when one of these members of staff comes over to you and tries to tell you how to do your job. It just furthers the bad relations. It’s bad because QA and devs need to work together, so when those relations break down the code suffers
There needs to be a combination of the Scientist and the Misleader or a “Thinks they are a Developer/Project Manager”. A tester that learns enough about the software on a developer level to be dangerous. Might be seen saying such things as “This feature isn’t working because you are not initializing your variables correctly.” Junior devs who don’t know better will take them at their word because, well, they sound like they know what the issue is. Will write bugs for new features they think should be implemented with no regard to project schedules or what software conflicts their change will cause.