Can ISO 29119 Software Testing "Standard" Really Be a Standard?

New submitter yorgo writes The International Organization for Standardization (ISO) will soon publish part 4 of a 5 part series of software testing standards. According to the website, "ISO/IEC/IEEE 29119 Software Testing is an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation." However, many in the testing community are against it. Some wonder how the ISO/IEC/IEEE achieved consensus without their input. James Bach speculates that exclusion helped build consensus. Others, such as Iain McCowatt, argue that something as variable as software testing cannot be standardized, at all. And others believe that the motive behind the standards is not increased quality, but economic benefit, instead. Michael Bolton explains "rent-seeking" as he builds on James Christie's CAST 2014 presentation, "Standards – promoting quality or restricting competition?"

A comprehensive list of many other arguments, viewpoints, and information has been collected by Huib Schoots. Opponents of ISO 29119 have even started a petition aimed at suspending publication of the standard. Even so, this might be an losing battle. Gil Zilberfeld thinks that companies will take the path of least resistance and accept ISO 29119.

So, where do you stand? What constitutes a consensus? Can a standard be honored without consensus? Can an inherently sapient activity, such as testing, be standardized, at all? What is the real purpose of a standard? Will companies acquiesce and adopt the standard without question?

Standards

[Crizzam]

Are rules for some and suggestions for the rest of us. The IEEE can put a standard on cleaning the toilet. If your company wants to follow it to the letter, or just use it as another reference, that's your call. I think the organization of conceptually difficult concepts is a good thing, overall. What we do with that is a whole other thing.

Can see it now:

[some old guy]

MBA CEO: I want our new product to be QA'd according to ISO 29119 before shipping.

Project Manager: Good idea, but that will add some time and overhead cost to my budget.

MBA CEO: Never mind, just ship it.

Shades of 2167

[Snotnose]

In the late 80s and early 90s I was involved in 2 projects run under MIL SPEC 2167, which was supposed to ensure product quality. Both were epic disasters. IMHO, 2167 pretty much guaranteed mediocre at best software, taking 3x longer to do, at a cost at least 6x of non-2167

This sounds like the 21st century version of 2167.

Re:Wrong focus?

[sinij]

You are incorrect. ISO standards are recognized by multiple countries. You can Google the full list.
 
The main advantage of any kind ISO is that it enables your software to get on government procurement lists. This doesn't impact small shops, they don't generally have resources or organizational maturity to sell to governments. There are multiple international, proprietary, and country-specific standards (e.g. ISO, FIPS, Common Criteria, PCI-DSS). International means you only have to go through certification once, not once per country that you were doing before the standard was adopted.

Re:Standards

[JeffAtl]

It's not quite that simple - customers can require the certification. If a customer is sizable enough, the suppliers will have comply to stay in business.

For real world examples, look at the power that the state of Texas has wielded in text book requirements and the state of California with warning labels.

Re:Automated test in is a minimum

[gnupun]

No. Unit testing is not a tester's responsibility. It is the responsibility of the coder to validate the code they wrote does the basic function it supposed to do.

Unit testing is white box testing and it's okay to get a tester to develop the tests as long as there's feedback from the developer about how the white box code is supposed to behave (internal behavior).

Should devs NOT test? Hell to the no they should definitely test.

Does the average dev have the skill set/ mind set of a tester? No. Even Microsoft often pairs a tester with a developer. Unit tests are likely to find as many or more bugs than black box testing and the typical developer will not be happy/motivated to find bugs in his own code.

So are you willing to deliver a buggy product just because you don't want to spend extra on test developers?