Standardization has been a source of considerable tension between individual, corporate and governing entities since the dawn of industry. The imposition of commercial and industrial standards first started to take off during the Industrial Revolution. In one of the earliest instances of organic, industry-driven adoption of standards, Henry Maudslay’s invention of a screw-cutting machine that could measure to 1/1000th of an inch spread throughout factories across England, which was a factor in fueling that country’s rapid industrial growth in the 19th century. Similarly, the success of one particular railroad in the United Kingdom led to the adoption of the Standard Gauge, which eventually won out against the design of other, rival companies. As the 20th century progressed, standards became critical to the development of modern society – from the distribution of electricity, to automobile design standards to the measurement of time.
In more recent times, the standardization wars have eventually been either settled by market consensus (see the VHS vs. Betamax and Blu-ray vs. HD-DVD format wars) or by a governing body choosing to enforce a norm when it deems it to be economically or socially beneficial, as illustrated by the recent push by the EU to standardize phone chargers. At its most basic level, the goal of government or industry-imposed standards is to coordinate to maximize the well being of the industry as a whole by promoting connectivity and reducing redundancy, while simultaneously communicating to end users or consumers that a certain good will work as expected.
Wait…what does all of this have to do with Testing. you ask? The ISO is preparing to complete the final draft of ISO 29119, which seeks to create an “internationally agreed upon standard for software testing that can be used within any software development lifecycle or organization.” At CAST 2014, James Christie offered an impassioned critique of ISO 29119, suggesting that the purpose of these standards was less about certifying a basic level of quality than an exercise in rent-seeking behavior on the part of large testing companies looking to become gatekeepers of “quality,” charging fees for certification and associated learning materials. This, according to Christie and others, would create a norm where companies seek testers with the aforementioned certification, forcing testers and companies to either comply with or ignore the standards, and bear the associated risks of each. He and others support this reasoning by citing the lack of buy-in from many segments within the Testing community, the high barriers for participating in the working groups (located in far-flung locations around the world) and the high cost of downloading copies of the existing portions. Those in support, such as Stuart Reid, take a different tack, citing demand for existing standards, a common, internationally-accepted set of terms and definitions used and a way to communicate to buyers that “good testing practice” was followed.
In the proceeding days and weeks, momentum spread from the conference floor to twitter and resulted in a a petition – which now has over 1000 signatories – opposing the adoption of the standards:
ISO29119 is an affront to the craft of software testing and must be revoked. Sign the petition demanding just that http://t.co/Zcg4qvjafa
— Josh Meier (@moshjeier) August 18, 2014
ISO 29119 holds up documentation-driven heavyweight anti-agile software development processes as the baseline of good practice. #stop29119
— Ben Simo (@QualityFrog) August 27, 2014
How, then, can one draw a line between the benefits of standardization against the potential dangers outlined by James Christie and others? One way to look at it is that the distinction is that the benefits and drawbacks of design standards for goods are distinct from processes. Design standards for goods tend to be much easier to specify and justify standards than it is for processes. Michael Bolton outlined this distinction in a blog post detailing his opposition to the standard, saying it is “ultimately desirable to describe and standardize widgets – tangible, physical things that have quantifiably measurable attributes…” That isn’t to say that these standards don’t have trade-offs, as designs must be made within the constraints of the standard, but these trade-offs can be much more easily estimated.
In part 2, we will explore the history of process and safety standards from other industries, the details of ISO 29119 and see if we can draw any lessons from the past.