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?