Chicken Little and the Tester Who Cried "BUG!"

We all know the story of Chicken Little – he sees something fall from the sky (an acorn) and is so convinced the sky is falling in, he spreads panic around his friends, and they go off to seek the King, but end up getting eaten by a sly fox who uses the panic to lure them to their doom.

It's a sad fact but in the world of testing there are a fair few Chicken Littles.  And if you have one on your project, your developers in particular will get tired of them pretty quickly.

On a previous project with EcoEnergy we reviewed some designs for a website with development and marketing. And we got from marketing “oh no – this is a showstopper, the red is the wrong shade”. Looking around the table the developers were incredulous, but recovered assuring this was a minor change, and would easily be resolved.  But for them the bigger concern was the fact that all the data they were receiving from the back end was wrong, and thus they were misleading the customer.

With both the acorn falling from the tree and the wrong shade of red, not big issues. The acorn falling was actually a known feature of an acorn tree.  I know it's easy to mock the marketers, but although getting the look right for them is important to them (an application which looks ugly isn't going to lure people), at the same time as the developers were right to mention it's easily resolved, and not quite the sky-falling-in showstopper.

As testers it's our responsibility to inform management and developers when big bugs come along.  The kind of defect that jeopardise product delivery and timescales. So for instance, the misleading data which means we're liable for misinforming our customers, the system crashes etc.

Time plays a big factor too.  If our logo issue was discovered the day before go-live, it would be more critical.  But likewise if you get a serious bug weeks out from delivery, it's kind of the norm, and as long as it's defected and put on a path to resolution, it's nothing to get too worried about at that stage.

I figure as testers we're like the boy who cries wolf ... or should I say BUG! If we say BUG! too many times, eventually people are going to stop listening. I mentored a tester who escalated every defect she encountered the same way, even the cosmetic ones – eventually all her emails were being left in developers intrays, because they wouldn't / couldn't separate the urgent from the cosmetic

It's a bad place to be in, because a tester who's let that happen has lost the trust of her developers, and it's a very tough place then to be effective and win that back.  With the tester I mentored, I managed to steer her to rate her defects, and the really important ones she should really try and get the developer in to see what she'd experienced as soon as possible.  It became so much easier then for developer and tester to work together and solve the problems she was finding.

As I've said privately many times before, nothing really beats having a developer or business analyst on hand to ask “hey is this right” when what you're testing looks wrong.