Testing's Men in Black

At a time when the world is watching the Rugby World Cup in awe of a certain set of men in black, it's interesting to see how this story has been doing the rounds on the internet – thank's to the Testing Club's Rob Lambert

http://www.t3.org/tangledwebs/07/tw0706.html

It's a no doubt apocryphal urban legend about IBM - but a lot of fun to read anyway!  In the 1960s the world of computing had a different emphasis – programming was a much slower business, and there was one shot at delivering software, no patching, it had to be right on release.

IBM supposedly found that programmers who wrote the code were blind to any faults in their software when it came to testing.  Some people though showed a natural aptitude, and thus one of the world's first test teams - “the Black Team” - came into being.

The Black Team were made up of the best-of-the-best when it came to breaking software.  They became a kind of bogey-man to terrify young developers, able to break any software they came across.  This tale here is just a brilliant parable of the supposed lengths they'd go to in order to test software ...

http://www.penzba.co.uk/GreybeardStories/TheBlackTeam.html

Tales of the Black Team go further, telling how team members started to form an identity together, wearing all-black to the white collar IBM offices.  Some even growing Dali-esque moustaches they would twirl sinisterly as they tested.

I'm very dubious – but I absolutely love how software testing, which feels sometimes like a very recent discipline (in New Zealand sometimes it feels not quite respected as a profession at all some days), has managed to pick up this urban legend.

But it also takes me back to one of my first posts here, on “what is software testing”.  The tale of the Black Team is all about a team who go out of their way to break things.  The story where they work out the resonant frequency of a large tape reader so it rocks itself over whilst reading a file is bang-on-the-money for a lot of people who see testers as people who just go out of their way to destroy.

Today in a management meeting it came out that the business owners see testing as a problem.  “The project was all going well until testing got involved”.  As if testers are responsible for the defects they encountered.  I think the reality is much closer to “we managed to delude ourselves that everything was fine until testing gave us a wake up call”.  If testing is done well there's no hiding the truth of where a project lies.

But no- testing is not about breaking things.  It's about proving quality.  And that can be a bogey man of it's own to a complacent project.