A QA who has declared that the entire product is of an unacceptable level of quality based only on their first impressions.
- Can mutate into: “The Blamer” or “The Firehose” QA
- Dangerous when coupled with: “The Pessimist” Project Manager
- Likelihood of fixing: High
- Danger to project: High
The nature of application is that quality from feature to feature will be uneven. Some features may be relatively simple, or developed by highly skilled developers, and therefore have little or no bugs. Some features may be relatively complex, or developed by less skilled developers, and therefore be riddled with bugs. The Alarmist QA tester has had the bad luck of having the first area they have tested be of low quality, and has therefore declared that the entire product is of low quality without any further investigation.
Much can and has been said about a developer being frustrated by a QA tester wasting their time (see “The Misleader” QA), but this situation cuts both ways. All too often, a developer will knowingly hand off software that they have not thoroughly tested in order to receive credit for completed work, or to claim they have met a deadline. When a QA tester begins to test such a system, they are immediately met with a host of bugs that should have legitimately been caught by the developer. It is therefore understandable that they would extrapolate what they are seeing to the entire product, and declare that the product as a whole is of too low a quality.
The Alarmist QA tester is normally someone with some level of authority within the QA organization, and therefore their opinion is well respected within the organization. The greater their level of authority, the more devastating their impact on the project. A typical disaster scenario is the following:
- The product is delivered to QA
- The Alarmist QA begins testing an area of the application with an appalling level of quality
- The Alarmist QA halts all testing efforts, and escalates to upper management that there is a severe quality problem with the product.
This is a classic case of throwing out the baby with the bathwater. Sometimes, QA will have made the right judgment call, especially when the development team has a reputation of passing off untested software to QA. When it is the wrong judgment call, however, it may have only been a single poor developer has made the entire development team look bad, as their work just so happened to be the first set of work tested by the Alarmist QA.
A QA tester becomes the Alarmist after having been burnt repeatedly by the development team. If the development team had consistently delivered high quality software to the QA team in the past, there would be no opportunity for an Alarmist to emerge. Once a QA tester has become an Alarmist, however, it may be difficult for the development team to win back their trust, especially if the development team includes The Incompetent or The Bull in the China Shop developers.
Typically – especially on large development teams – low quality is caused by individual developers rather than the team as a whole. It is therefore imperative that work done by these less competent developers be last on the list to verify, or effort must be taken to not have the Alarmist test their work. Doing this, however, runs the risk of masking the true issue: that there are developers on the team negatively impacting the project.