A Tester who floods the developers with so many bug reports so quickly that they overwhelm the development team with a backlog of bugs they will never finishing working through.

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

Problem

When a bug is found, it is important that it is reported accurately and then quickly assigned to the appropriate developer to fix. However, there are QA testers who can find and report bugs so quickly so as to exceed the development team’s ability to fix them, creating an ever-growing list of bugs that can never be closed.

On the surface, this can simply be interpreted as the product having severe quality problems, however, that is not always the case. The Firehose QA tester, as opposed to a normal QA tester testing a system with a lot of bugs, is creating a storm of bugs with any or all of the following characteristics:

• Their bug reports are not very detailed, allowing them to report more bugs more quickly.
• Many bugs are duplicates of others, as they are only variations of a single root cause.
• No time is spent reproducing a bug, as seeing a bug once is all that is needed to generate a bug report.

Firehose QA testers are often created through direct or indirect organizational pressure: the more bugs you find, the better you are doing your job. This results in QA testers who are diligently tracking down the actual root cause of the bugs, and reporting them clearly and concisely being seen as less productive than the Firehose who is merely going for number of bugs reported per unit time.

The Firehose’s effect on a project is sheer panic, as they give the impression that the product was built poorly, and that the project is now behind schedule. Their effect on morale can be immediate and dramatic, causing the development team to throw up their hands as they wait for a break in the onslaught of bug reports.

Solution

Before any effort goes into fixing a Firehose QA tester, it is vitally important that you identify them as a Firehose, rather than an efficient QA tester testing a bug riddled system. The clearest indication is the following complaints from developers:

• Most bugs are duplicates of others.
• Many bugs have the same obvious root cause, and therefore could have been reported by a single bug.
• Bug reports lack detail.

The solution to a Firehose QA is to inform them that there is no incentive to report a high volume of bugs, but rather that the goal is to improve the quality of the system. This shifts their focus from reporting as many bugs as possible to helping developers find problems in the system. Quality should then improve at the same (or better) pace, but without the panic.