Is Software Testing a Thankless Job?
What are the traits of a thankless job? In my view, a thankless job is one that gets all the blame when things go wrong—and hardly any credit when things go right. If you’re a sports fan, think NFL placekicker. After attending numerous software conferences and conducting dozens of interviews, I’ve begun to notice that many testers see themselves as working in a thankless profession.
To illustrate this point, I’m going to highlight three particular problem areas that are almost always blamed on testers and the QA departments—and wrongly so, I might add.
Missed Bugs
Whenever a bug makes its way into production, the QA department is almost guaranteed to hear something along the lines of, “Why didn’t you catch that bug!?!” This blame often originates from a misunderstanding of what the role of testing and QA is and what it ought to be.
Missed Deadlines
If your testing team hasn’t been blamed for a missed deadline, then you haven’t been in the business long enough. Unfortunately, testing is seen as the last line of defense in many companies. This is a dangerous mindset to adopt. While it may work when an application is delivered in good condition and on time, it backfires when the application is delivered in poor quality, with a tight deadline approaching. In the case of the latter, when bugs are discovered, testing gets blamed for either not having found them sooner or for nitpicking.
Poor Quality
Apart from missed bugs, test teams often get blamed for poor quality in general—poor performance, poor usability, or any other common end-user complaint. It’s been said by multiple people that quality cannot be tested into a product, yet it’s still a major pain point for QA and test teams. Like some of my previous points, testers and QA teams are partly— but not entirely— to blame for low quality products.
Consider, for instance, the source of the “poor quality” complaint. Let’s say a recently launched application does not fit a business need for the end-user. Here’s author Michael Krigsman with a good example of what I mean:
The biggest complaints about operational business applications are that they just don’t do what business users wanted. Consequently, employees implement endless workarounds, managers use hidden spreadsheets, and the business fails to benefit from its application investment.
Can the poor quality described in Krigsman’s quote be attributed to a failure on the part of the test team? Not by a long shot.
More detail about these three points can be found on the uTest Software Testing Blog .
