Stop ISO 29119

So, there is a proposed ISO standard for software testing, ISO 29119, which is causing an awful lot of controversy in the testing world.

Stop 29119Just about every software testing professional with an online presence is concerned about ISO 29119′s likely impact on the profession. The consensus is that forcing a highly bureaucratic one-size-fits-all cookie-cutter approach to testing across the whole software industry is unlikely to result in higher quality software, but will almost certainly stifle innovation and inhibit exploration of new creative approaches.

Rob Lambert is just one of many with serious reservations, and James Christie has this to say:

I’m afraid my hackles rise when I see phrases like “one definitive standard” and “used within any software development life cycle”. It immediately triggers an adverse emotional reaction as I remember this rhyme from Lord of the Rings, about the One Ring that would give the holder power over all.

“One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie”

Unfortunately it’s not something that anyone can guarantee will just go away if people ignore it.

Naturally those whose businesses revolve around selling consultancy to middle-management are going to support the introduction of a standard. As will the certification mills. And don’t even mention lawyers. I’m sure we can all easily imagine technically-illiterate politicians demanding that ISO 29119 be mandatory for all government contracts. After all, everyone knows that those gargantuan government IT failures we keep hearing about in the media are entirely down to sloppy software testing and have nothing to do with reality-denying project management.

There is now a petition against it. If you think ISO 29119 is a bad thing, go and sign it.

But not everyone agrees with the petition. Although this ridiculous Godwinesque screed hardly helps the cause:

Their objection is that not everyone will agree with what the standard says: on that criterion nothing would ever be published. The real reason the book burners want to suppress it is that they don’t want there to be any standards at all. Effective, generic, documented systematic testing processes and methods impact their ability to depict testing as a mystic art and themselves as its gurus.

I would say that resorting to personal attacks of that nature is strong indicator for the bankruptcy of their argument.

This entry was posted in Testing & Software and tagged , . Bookmark the permalink.

10 Responses to Stop ISO 29119

  1. James Christie says:

    Thanks for the support Tim. :-)

  2. Pingback: Five Blogs – 24 August 2014 | 5blogs

  3. John P. says:

    It sounds like the BS5750/ISO9000 stuff from the early 2000′s. I can see that it is probably well intentioned but it won’t happen that way. Companies will simply do the absolute minimum to comply without doing anything meaningful or useful or entering into the spirit of the thing. So it will be a case of just documenting something general like “test it works as specified and retest if anything changes” without saying anything specific about what that involves and then hang the certificate on the wall.

    A pointless waste of time but you only have to do it until everyone has forgotten about it. I mean, BS5750 was a buzzword back then but when was the last time you saw anybody bragging about having it these days? It’s a fad that will be forgotten.

  4. Tim Hall says:

    The trouble with this is I can imagine precisely the sort of test manager who will be enthusiasic about ISO 29119. Those types who think the deliverables for testing aren’t software that works, but reams of documentation all in the correct format using corporate-approved templates, which can be filed way where nobody will ever actually read them.

    Sadly I’ve worked for people who think like that.

  5. Synthetase says:

    “Those types who think the deliverables for testing aren’t software that works, but reams of documentation all in the correct format using corporate-approved templates, which can be filed way where nobody will ever actually read them.”

    Wow that perfectly describes my girlfriend’s workplace’s ‘project management office’. Notice they aren’t called the ‘project delivery office’. They aren’t interested in delivering projects, just spinning the wheels and filling out forms.

  6. Tim Hall says:

    Have you ever read “Parkinson’s Law” by C. Northcote Parkinson? Written way back in the 1930s, but still relevant today, it describes that sort of workplace perfectly.

  7. Michael says:

    I’m not yet sufficiently informed about this standard to pronounce upon it, but in my workplace there are still two different streams of thought.

    The first group, mainly in the development community, assert that automated testing has to be mandatory.

    The second group, mainly in the support community, see the test scripts as nothing more than extra support overhead and ignore them. Once the test script no longer tests the code, it isn’t worth running and it is never worth bringing one back up to scratch.

    I’m in favour of test scripts provided they do something useful. A test script which is there simply to satisfy an automated system rule which states “you cannot submit code to go live without a matching test script” is in danger of abuse.

  8. John P. says:

    Project damagers – love ‘em or loathe ‘em, you just can’t avoid ‘em.

    Automated testing is a lovely idea in theory but it crashes into the buffers of reality. If scripts are to be any use, they have to be very comprehensive. It takes time to build them and more time to maintain them – either because of changes or because you’ve found some scenario that the original build didn’t test. In general, the customer isn’t willing to pay for the supplier to do this work and the supplier isn’t willing to do it FOC. So you just end up with a script that is pointlessly simplistic and which gives a false sense of security or you find that it is quicker and more versatile to get somebody to do the job manually.

  9. Tim Hall says:

    Automated testing has a role, to replace the tedious, repetitive bits. It’s never going to replace manual testing, and any management who think it can have fallen for snake-oil merchants.

  10. Michael says:

    John, my last major project simply could not have been delivered without a comprehensive test suite. With only three people left in the company who understand the business rules and only one and a half of them available to the project all we could do was capture as many test scenarios as we could.

    Since then there has been zero resources available for UAT so urgent changes have had to go live with minimal testing. These changes are ablating the value of those scripts, and as you observed maintaining those scripts is not seen as valuable.

    Eventually the whole edifice will collapse. The business risk being taken, and I hope this is understood, is will the system decommissioning date arrive before that point.