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.

Indecision and other vices ...

Indecision

Following on a little bit from yesterdays talk of indecision, it's time to talk a bit about Foxhole Norman.

We've recently been rewatching the excellent Band of Brothers.  Norman Dike, aka Foxhole Norman is an archetype all too familiar to anyone who's worked on a software project.

He was a replacement officer for Easy Company and described thus,

Lt. Dike wasn't a bad leader because he made bad decisions. He was a bad leader because he made no decisions.

Rather than fighting, he would usually remain in his foxhole.  If there was a crisis he'd try and return to base for more orders.  He was constantly absent.

He embodied indecision in a place where indecision was deadly.

Rashness

On the other end of the spectrum is acting rashly, which has equal perils.

As kids at Junior School we were often told the tale of Gelert the dog.  He belonged to  Llywelyn the Great,, a Welsh Prince, and was his favourite hunting dog.  However one day Llywelyn comes home to find his infant son's room ransacked, and his son missing.  But there is his dog Gelert covered in blood.

So Llywelyn draws his sword, and kills Gelert there and then.  But the dog's dying yelp causes the hidden child to cry.  Looking around the room, he sees in actual fact there's a dead wolf in the room, and Gelert has died protecting his son.

Overcome with remorse for what he's done, he builds a memorial to the dog, and curses his rashness for the rest of his life.  When Mr Barrett told that story there wasn't a dry eye in the house.

This teaches us not to act rashly, and indeed acting rashly is worse than indecision.   It's good to want to know more before making a decision, but how long do you leave it?  Collecting more and more and more information on any task does not mean in the end you're actually achieving, eventually it means you're wasting time and not actually doing anything.

Another Way

Sooner or later you have to make a leap of faith.

Ironically the longer you leave making a decision, the bigger that decision will have to be, and the more critical it'll be you make the right one.

Make decisions early, try to make their impact small, review them regularly.  If they're wrong you'll still have time, and almost always something is salvageable.  It sounds like I'm going all Agile again, and maybe I am.

Just don't be a Foxhole Norman ...

The Curse of Indecision

May was a quiet month on the blog front, as our family sadly dealt with a death in the family, my father-in-law.

Dealing with death is about one of the most traumatic things most families deal with.  And there is an awful lot to organise.

In my father-in-law's case, a will could not be found detailing his wishes, and an awful paralysis crept in amongst the family.  Because no-one had a piece of paper with his wishes, no-one decided anything to do with his funeral, what kind it would be, buried or cremated.

Everyone was so frightened about “getting it wrong” and being judged to have gone against his wishes, no-one did anything for over a week.

This is probably the worst kind of decision paralysis – not making a decision didn't change the fact he was dead or that he'd need a funeral.  It took a lot of courage for one sister to go “I think he'd want ...” and everyone fall behind that.

Indecision is probably one of the worst thing in any project.  Indecision is often disguised as waiting for more information, but really it's often just putting off the point where a decision will be made,

In my book it's always easier to work with a decision which creates problem than just waiting on hold for any decision to be made ...