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 ...

The Death Star wasn't Agile - the video ...

Yep - why read, when you can just watch!

Are you not entertained?  

The Death Star wasn't Agile – and other Imperial failings …

This started as a joke I put up on Twitter, but the more I thought about it, the more I feel how we could learn a bit from the Empire, by looking at how they run projects, and how not to fail like that in our teams.

1)  Death Star Vs Alderaan

The Death Star is a planet killing ultimate weapon.  Woot!  And part way through Star Wars IV A New Hope, it appears above Alderaan, and blows it to smithereens.  

This Governor Tarkin claims this is the first demonstration of it's firepower.

Now if this was a truly Agile project, then in the first part of the film, the Death Star would have gone around blowing up an asteroid first, then a small moon, before moving onto Alderaan, to effectively show the capability of it's destructiveness in a couple of iterations.

Okay so the Death Star worked - but what if it hadn't?  Instead of feared throughout the galaxy it'd have been on the "and finally" section of the news.


2)  Getting the Death Star working

There is a gap of 20 years between the films Revenge of the Sith and A New Hope.  In A New Hope it's said that the Death Star is only just operational.

And yet in Revenge of the Sith, the Death Star is shown under construction – that means they took 20 years to finish it and work the bugs out of the system!

Ever heard of deadlines?  C'mon we've got a galaxy to run here!

3)  Blowing Up The Death Star

The plans of the Death Star appear in the second film, Attack of the Clones.  In A New Hope, the Rebel Alliance get a hold of them, find a weakness (the exhaust vent leading to the main reactor) and attack it.

Yes – it took over 20 years to get the Death Star working, but they kept to the original plans – they never went “wait a moment ...” and thought of a better way?

4)  Stand-Up Meetings

The Empire never got the hang of stand up meetings.  Look at this – only Darth Vader is getting into the spirit of it.  And even then he ends up force-choking another member.  Which is a novel way to keep meetings from over-runing.

5)  Armour Plated Solutions

In the Battle of Hoth the AT-AT walkers won victory over the Rebels landspeeders.  Ish.

The AT-ATs were better armed and armoured.  They won, they took out the bases reactor and shields.

But they were also very slow.  By the time they got to the reactor, the Empire had given their competition the Rebel Alliance enough time to get ahead of them and move on to a new base.

Had the Empire used landspeeders themselves, they could have quickly taken out the reactor, and wiped out the Rebels there and then.

6)  Embracing Failure

No-one in the Empire really learns from failure – as they often end up being force-choked to death.

This is particularly bad as sometimes the one to blame for Luke Skywalker getting away is Darth Vader himself.  Poor management.

7)  Hoping the Little Problems go away

On Endor, the Empire was plagued by little fury pests.  Rather than deal with them decisively, the stormtroopers just hoped they'd go away and not bother them.

In the end those pesky Ewoks ended up ganging up and becoming a giant problem which brought down the Empire.

When you can, exterminate those Gremlins before they gang up on you!

Communication - the better ways of doing it ...

So I've chewed out the "bad" ways we sometimes communicate - what are the good ways to do it?

The project I work on has got communication down to a T, and their rules are pretty good.  They call them Agile-ish or "pragmatic development".  Having got used to them, I find them pretty smart.

If you have a technical issue,

• try and find the person you need to chat with, and talk
• failing that, book a meeting
• or else phone them
• only if all the above fail, write an email
• if you write an email - no more than three paragraphs.  Keep it short and to the point.  No massive lists, no more than a few points.
• keep documentation brief and readable

We're trying to come up with new ways of displaying information.  For instance I have been talking with my Testing Learning partner from my old company.  We both have the same worries - you write your test plan, but does anyone read it?

A solution suggested from Agile Testing by Lisa Crispin and Janet Gregory is to produce a 2-page test plan of the salient points.  What I've since been working on was an idea suggested by a couple of people from the Software Testing Club - a mind map!

Basically at the moment (it's a crutch I know) I'm still writing out my traditional 12 page test plan, but supporting it with an A3 mind map based on an structure provided by Ivor McCormack ...

It's truly a thing of beauty isn't it?

I've used this for two projects so far and been amazed - I put this in front of a manager or developer, and within a couple of minutes we're cutting to the chase, and discussing testing effort.  It's that intuitive and easy for another party to pick up - success!!!


My study partner has also seen this, and taken it to use on her project.  I'd like to take credit, but it's a collaborative effort, and proof how testers through the internet can share stories and education to help each other.


At the moment the traditional test plan exists in the background, but I'd like to eventually move to just a mind map.  I don't know if it's possible, but it would really ease things if we could.  Everyone seems to love them, and it takes 5 minutes to pick up vs hours of review!

Project Communication

Over on the Software Testing Club I've been talking a little bit about communication within teams and it's been interesting to see how passionate the responses have been.

We've all been there – been given a series of planning and design documents for our project.  They're very long.  And dull.  And when you're reading it, it goes

“The system will readily maximise future leverage in the marketplace under the caviat that increased technical processing will accelerated – blah blah blah – oh this is so boring”

Yup – and there's usually about 60 pages in that vein!

Over the last few years I've read some truly mindnumbing documents.  We then send them to the customer, and get really irate they never comment back on them.  Or worse still when we deliver and they go “why does it do that?” we go “but we told you in that 400 page technical spec!”.

Why are we making it so difficult?  Let's step back from the problem first and ask – how would we as engineers solve a similar problem of communication if we were dealing with a technical computer based issue?

So like the SOA examples I've talked about previously we need two computer programs to communicate how would we deal with it?

First off we should be going “why are we communicating”.  Most communications fall into one of what I call “the 3 i's” …

• Instruction – telling another party to do something
• Information – providing another party with data of some kind
• Inquiry – asking another party for information

So whatever we're communicating for the computer, it had to fall into one of those.  If it's not, then it's just waffle / overhead, and we need to bin it.

We then take a lot of time thinking about protocol – we want the messages we send to another system to make sense there, and likewise we want the information we receive to make sense to us.  We also know that brevity is key – if we make messages unnecessarily long, we know it'll consume bandwidth without really delivering any kind of value or service.  If not, then once again it becomes an unnecessary overhead.

We are super-optimised when it comes to dealing with communications between systems.

Why then are we so bad at communicating with each other?

No really we are!  We're so good at the rules of communications on computer systems, we know its a complicated minefield, so we treat it with respect.

But we've known how to write since school and been talking since we were about two.  Easy peasy, it just comes naturally hey?

And so we run meetings which constantly run overtime, but don't go anywhere.  We write reports which are too meandering and too technical for the audience, and no-one reads anyway.

No – no – NO!

Let's try this again.

Every email, memo, report we write needs to be tailored just as we'd design a computer message.

We need to make sure it has purpose – that it either informs, instructs or inquires.

We need to make sure it has protocol – that it conforms to an easily understood standard by the intended party, and has the information they need without unnecessary length.  That it is targeted for it's intended audience.

We also to use plain English where we can.  Sometimes we expand what we write with buzz words and jargon because we feel it gives a certain grandeur and polish to what we say.  I know many a person who's a bit guilty of using a “posh word” in not quite the manner they really should.  Instead of looking clever, they look stupid, and this can also mean confusion creeps into what they're doing.

If not careful we can become like some aging thespian saying “To be or not to be.  That is the question.  Whether tis nobler in the mind to suffer the slings and arrows of outrageous fortune.  Or to take up arms against a sea of troubles, and by opposing, end them”.

Most kids if you said that to would go “huh?”.  However if you said “Look shit happens.  Either learn to take it or give some back alright?”, they'd go “ah”.    Targetting for the audience you see.

Some of you might say that's not proper English, but then (and no offence, as I love his work), neither is Shakespeare these days.

Let's keep it simple eh?