Why I am tired of having to justify testing's existence ...

It sometimes seems that there is nothing more turbulent and egotistical than the music industry.  I know this having friends who've been in bands, and indeed following the troubled life of some of my favourite bands like The House Of Love.

It's an all too familiar scenario - put so brilliantly to celluloid in films like The Commitments and This Is Spinal Tap.  Recurring motifs seem to be,

• The guitarist who thinks the songs should be built around his sound
• The singer who things they ARE the band
• The bassist who just does their own thing
• The drummer who gets dirty looks and the blame if someone messes up a song, and who occasionally somebody would be cheaper to replace with a drum machine.

Egos galore - everyone thinking that it's their instrument and talent which is/should be dominant, and the cause of success.  The hardened truth is that the band's sound is a contribution of all the talent at work, not just one element ...

• A Freddie Mercury song doesn't sound quite the same as a Queen song (and they certainly don't sound the same without him).
• The Smiths last album didn't sound quite the same without the guitar of Johnny Marr.  Likewise for The House Of Love when Terry Bickers left.

Much like for agile teams, there is no "magic line-up" for a good band.  The one thing that seems to be agreed though is you need some kind of variety - even an acapella band which has only singers has singers with different vocal ranges!

Rivalling the music industry for turbulence though has to be the IT industry, especially with agile groups.  This really shouldn't be a surprise - the same human dynamics and egos are in play, the fact that it's a different field changes the context a little, but there are surprising similarities.  As was reinforced to me this morning.

Bob Marshall generally tends to talk a lot about his values of non-violent communication when it comes to dealing with developers such as himself.  I've however found his attitude a bit frustrating, summed up best by Lisa Crispin ...

I have to say Lisa's responses really summed up a lot of frustration out there.  I've noticed a bit of behaviour similar to this on Bob's Twitter before, where I've felt he's been playing the role of prima donna developer a bit too much, and has shown behaviour which has felt like being a borderline troll at times.  This is especially as he believes in non-violent communication ... but only when it applies to managers telling developers what to do.  Ultimately though, I'm reminded of the pig Napoleon from Animal Farm, who wants to do away with manager-led dictatorships, and replace it with a developer-centric one.

I want to be fair to Bob, because he did do a very similar Tweet about "funny how few devs/managers question the basic premise of their trade", however this was very after-the-fact, and did not include the tirade against testers which I've found a little too frequent on his Twitter of late.

I'm sorry, but I side with Lisa on the complete frustration on this one.  I have had to come up across similar attitudes, and often from developers about how little testers contribute.  And I'm getting a bit tired of having to have it - ultimately the best way to judge the value of testers is to try delivering to production without one, and let me know how that works out for you.  Most of the cautionary tales around the IT industry tend to revolve around "we didn't test enough ... but got it into production on time".  But we still seem to occasionally have someone who thinks it won't happen to them or that "testing costs too much, and gives very little value".

What we're left with then is very much the rock star band model above.  We have a small group, but big egos.  We're used to the idea of the lead singer / "software manager" who thinks they run the group, and their word is law.  Sadly Bob is not alone amongst the developers I've met (thankfully far from all), who is a guitarist who thinks the best kind of band would ONLY have people on guitars, because guitars are cool.

Sadly I feel sometimes we testers are considered to be the Spinal Tap drummer of the group, who can be easily replaced, perhaps with a machine (sound familiar?).

One problem with perceptions of testing is one I've been talking a lot on Twitter about.  When I learned software engineering from a book by Michael J. Pont (I am a programmer remember), I still remember the opening which talked about increasing complexity in software (and this was back in the 90s).  The core to being a software engineer is about managing that complexity and breaking it down, further and further until you were left with something simple.

Now - and this might be a shock - but the same is true of testing.  Testing is a big, complex, amorphous heap of unknown.  As testers we use experience, inquiry and investigation of every possible aspect of a piece of software and form a strategy to break this down.  I was pleased to read Sami Soderblom's post which repeated this theme.

You might use a matrix or a mind map or even a test planning tool.  But sooner or later you've broken it down to the simplest unit you can - a test scenario.  And sadly on seeing this simple, individual test scenario, the reaction is all too similar "anyone could do that" (execute the test scenario).  Without appreciating that the skill in testing is being able to apply strategy to come up with those scenario.

Working alongside good agile teams, I'm often hit with the same comment from developers - that we test scenarios and find problems they just wouldn't have thought of doing.  This is because knowing the strategy and application of heuristics is as skilled as any subtle programming language.  And many of us have learned this by using software over decades.  And like any trademan, what we do looks incredibly simple, until you have someone inexperienced try it.

But for some reason we don't see this in reverse.  If a developer broke her hand, and I had to help her meet a deadline by typing the last line of code,

obj.sum = value_1 + value_2;

It could be argued that the line is very simple, and easy to understand.  So maybe development isn't so hard.  Heck - maybe because I could type that line, I should say we don't need developers any more if it's so simple?


Fundamentally any team like any band needs some kind of diversity of skill within it.  Coding is an obvious must.  Testing not so obvious - but believe me, if you have no-one skilled in testing, eventually you'll know about it, and it probably won't be pleasant.

Finally ...

I got the following response from Bob this evening ... obviously he has some super-secret recipe for success if you'd like to try it ...

Or else he's just leading a lot of his followers into dangerous waters ...

Additional reading

Since I've written this article, a number of people have given me similar articles they've blogged about, and I'm going to include them here ...

• Sami Soberbloms article 
• James Thomas's article
• Albert Gareev's article