The bearer of bad news

I was just thinking about this the other day, and then just now I saw Dave Whalen’s post on “ugly baby syndrome”. Software testing’s a difficult job, and I don’t mean technically challenging, I mean socially difficult. Often we’re associated with an attitude of negativity. This is our conundrum:

• Our job is to find faults in the software.
• If we say the software is fine and it isn’t, it looks like we didn’t do our jobs.
• If we say the software isn’t fine and it is, it looks like we don’t know what we’re talking about.
• If we say the software isn’t fine and we’re correct, we’ve done our jobs right, but now other people have to do more work to fix it.
• If we say the software IS fine and we’re correct, then champagne and pats on the back all around (how often does that happen?)

We’d all like to be able to say the software’s fine, but it’s a risky move – we can never state with absolute certainty that the software is bug-free.  So testers say things like “all of our tests have been run and no bugs have been found”. Or “to the best of my knowledge, the system should operate as per requirements”. You’d think we’d make pretty good politicians, really.

In addition, testing is one of the more thankless jobs in IT – how often do we get thanked for the bugs we prevented? After I took this job, I was given kudos for a job well done after a release and I was totally blown away, because that hardly ever happens in testing.

So here’s my advice to any testers, or wannabe testers:

• Be prepared to look like an idiot. Sooner or later you’re going to raise a bug that’s not really a bug, or raise hell over some bug that only occurred because you had a donut leaning on the Windows key. Big deal. Raising non-bugs is an unfortunate side-effect of testing. Better to raise the bug than risk the bug being missed.
• Stay real, but stay positive. Sounds strange to stay positive when your job is focused on the negative. It’s a perspective thing- you’re not breaking the product, you’re helping the team fix the product. Remember you’re allowed to compliment the product as well.
• Be objective. You could try using passive voice, if you find objectivity difficult. Don’t say things like “this is crap” or “this is broken”. Instead describe the behaviour you’re seeing. It’s okay to have opinions, but make sure you differentiate between your personal opinion and your objective analysis, e.g. “the new sign-up screen works correctly, but I personally found the layout a bit difficult to read.” (instead of “the layout on the sign-up screen is too difficult to read”)
• Stay cool in the face of danger. Sooner or later you will encounter hostility – you’re the messenger, and you may get shot because of it. Just keep your cool, stay positive, and try to work with the person (or persons!) to focus on the solution rather than the problem.
• Promote your work. The benefits of testing are not always obvious to the rest of the team, or to the higher-ups. Nobody is going to dig deep to find the benefit in your contribution – it’s up to you to show them what you’ve achieved. Report on how many bugs you found for a release (and therefore prevented from entering production). Share metrics with the team showing an increase in quality. If developers are producing better work (and you’re finding less bugs), comment on how much this has improved.