Home » Software Development » Why Testers Are Losing The ISO 29119 Battle

About Gil Zilberfeld

Why Testers Are Losing The ISO 29119 Battle

The ISO 29119 is making waves in the testing communities, regarding its content and necessity. Its focus on test planning and documentation gets modern testers to ask why.

I’ve worked in an ISO certified company, so maybe I can shed light from my past experience.

  • ISO standards are written by committees, which are made of people. We’re assuming that these people are experts, but mainly they are not. Some of them are academics who didn’t experience real life work.
  • There’s a big hidden assumption, that adhering to the standards ensures quality and stakeholder requirements. This is why management gives them the go ahead, apart from the certificate on the wall.
  • ISO certification are for organizations, not people. Most of the work in handling the acceptance, checks and certification are not by done by the practitioners. For example, in my former company, the person in charge of adhering to the ISO standards in R&D was not a developer or tester, and was outside on R&D. She was very good at what she did, but did not have any product development experience.
  • There’s a great fear of not failing to meet the ISO inspections, and therefore they rather go specifically according to a standard, which is specific about what they need to follow, if there is one.
  • ISO is really simple: Define your process, prove you adhere to it, get certified. In my former life, all development procedures were NOT dictated by ISO, but by the organization internally. They were derived indirectly from ISO 9000. To get the annual certificate we needed to show proof that we actually did what the procedures said.
  • As non-practitioners lead the process, there’s a need to create a common ground in terms of process and language. How would a general QA manager (non-tester) know that the development team are doing code reviews? The practitioners need to document it.  In the ISO 29119 case, the documentation is of test planning and documentation. These are the easiest to put in process form, as real testing skills are hard to put into process, it’s an easy way out. Don’t worry, it’s not just testing, but every high-skill suffers the same fate.
  • Of course, test plans and test result documentations do not guarantee any quality, or guide people to test better.
  • Finally, the environment is there too: Even if you’re not in a regulated industry, which is required to meet standards, you’ll find a competitor who does get the certificate, and will push your organization for taking this on too. The ISO institute gets money from the inspection so they have an interest to push the standards to be adapted by many.


Let’s summarize:
An organization wants the certification because they need it, or believe it will help their quality. They are looking for the best, simplest and less risky way to get it. The ISO organization gives the simplest common ground that works with “documentation as proof” concept. Everybody’s happy.

Except the practitioners.

The uproar against traditional ISO standards is not new. When we decided that code reviews is needed, we had to document them, just so we can meet the standard. I needed to sneak in “documentable” features and tweak the form to pass an inspection. And all I wanted is an abstract framework for doing code reviews, where people pair and inspect the code for problems, not the location of braces. But that’s life. I had to compromise.

There’s a whole system out there that works fine for most people. A vocal minority won’t change that.

The antidote does not come from regulation and standards. It comes from the responsibility of the organization to learn and improve.

Do you really want to be just a standard organization, or a bit more?

Reference: Why Testers Are Losing The ISO 29119 Battle from our JCG partner Gil Zilberfeld at the Geek Out of Water blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....



One comment

  1. while manufacturing test engineer for 8 years at one company i was tasked to reverse engineer existing test systems and bring both systems and associated documentation up to current. at the same time, company got the ISO 9000 certification.

    it was not just about software, when they got the cert. ALL departments in the company had to play their part in updating internal processes.
    we had 300 different micro-controller based products with several versions to each. that translates into thousands of electronic test fixtures, embedded test software, test procedures, test plans, test firmware, product firmware, product software, ect. All these items required documentation trails, in house standards developed to create trace-ability.

    additionally, the way it was when i came on board is the mentality of ‘throwing the design over the wall’ to production. the developers then don’t have to worry about it at all any more. in the real world, that was not the case. documentation is created so others can pick it up and quickly get running to recreate test system, or upgrade existing test system. the ‘old’ way of doing it was information passed by word of mouth and/or test tester documentation passed hand to hand.

    further, with respect to SDLC practice, also applied to hardware in part, practices like Test Driven Development(TDD) has to involve test engineering development side by side with development team. Further, don’t do it half way like getting involved at design review time. this is already too late in the process. I have seen far too many design mistakes due to trigger happy marketing folks pushing a design through the system ending up with product/option that is defective by the time test engineering development gets their hands on it. So TDD, Design For Test(DFT), Built in Self Test(BIST) are applied.

    Myself, I have never seen ISO 29119 and what it entails yet. I have signed up for webinar coming up soon to learn more.

    my two cents.

    Ron Harding
    Bay Point, CA

Leave a Reply

Your email address will not be published. Required fields are marked *


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.