Stop 29119

The AA battery is standardized on current and size -- and interface standard. It was the /lack/ of a content standard that allowed the battery to improve over the past 30 years - from standard to heavy-duty to alkaline, all the while getting longer-lasting, less likely to leak, able to withstand greater temperatures, longer storable, and so on. ISO 29119 is a content standard; it will inhibit the progress of testing. Not only that, there is no consensus within the field on this and the methods advocated haven't been tried - that is, the standard does not emerge from practice. For evidence of this position, I would suggest one look to the IEEE standard 829 - another content standard that did not emerge from practice, and what become of it.

A standard that does not reflect the opinion and practices of the professional community.

* A standard where you have to pay to even know the standard, doesn't encourage discussion, and so it hinders improving said standard. * It doesn't make any sense to have a standard based on information from only a single point of view, i.e. the wish that there would be such a standard. * Where is the proof that this "standard" works any better than, let's say, inviting your kids over to work to start testing? Did anyone even *test* the theories that support this "standard"? The documents should at least be public property, so they can be discussed & tested in public (with the ability to reference the source materials without having to pay for it). That way, whatever *can* be standardized, might become a bit more apparent. Even if I personally don't believe there is much that can be standardized yet, I'm willing to discuss it.

The AA battery is standardized on current and size -- an interface standard. It was the /lack/ of a content standard that allowed the battery to improve over the past 30 years - from standard to heavy-duty to alkaline, all the while getting longer-lasting, less likely to leak, able to withstand greater temperatures, longer storable, and so on. ISO 29119 is a content standard; it will inhibit the progress of testing. Not only that, there is no consensus within the field on this and the methods advocated haven't been tried - that is, the standard does not emerge from practice. For reference, consider another test process standard, IEEE 829. It also did not emerge from practice, had a mixed reception, and is mostly irrelevant to testing today.

James Christie writes: //According to ISO a standard should enjoy consensus, which is defined in ISO/IEC Guide 2:2004 as follows. “Consensus: General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments." The petition argues, correctly, that there is no consensus. Further, the process did not seek to take into account the views of all parties concerned. The standard reflects one particular view of how testing should be conducted and marginalises those who disagree.//

The proposed standard is a self-serving revenue generating standard and as such is not open to true discussion, modification, nor innovation. Additionally, it did not seek nor include those who are thought leaders in the testing community throughout the world, even those who generally support and do not support standards. Therefore, it is unethical, unjust, and unequivocally should be denied.

I am not aware of the methods applied to ensure maximum participation from testers across the globe to get a consensus on the standards. Makes it almost a fraud case to still call yourself a "internationally-recognized and agreed standards for software testing". With less than 80 testers(??am not sure if they are testers??) and a site that has News last updated in October 2013 - is it really sensible to call one a recognized standard. We have local community meetups with more participation. What kind of projects and clients today are looking for such huge documentations. This seems to be a step backwards and frankly I would not have noticed it had it not been for this petition. Though the standard seems to be jeopardizing in nature for the progress software testing is finally making, I personally think these are pretty ignorable too. No one really talks about them.

Treat All treat None. I am personally pretty un conviced with the Notion called ISO/IEK 29119. It would be great if we Understand that Testing is not a Generic Activity and Further in context with the fast changing world where every New Day is a Brand New Day

The working documents and published standards I have read do not appear to me that different from the IEEE 829 published in 1998 much less the later ones. There have been some minor changes to terminology but the basic structures and best practices seem largely unchanged. I fail to see how a concept initially proposed back before agile, mobile apps, big data, continuous deployment, lean development, cloud computing, and almost two decades of other practices and technologies can in any way shape for form be termed an "industry wide best practice."

Software testing has not approximated a consensus even on its vocabularity, let alone the basic processes. Leading people in the field often disagree about whether a given practice is good or bad. In some cases, the differences of evaluation of the same practice range from should-be-mandatory to indicative-of-incompetence. We see strong divergences within the academic community as well as within the practitioner communities. The "standards" movement within software testing has long been heavily politicized. Their objective seems to be to impose a set of ideas on people who would not otherwise agree to them, "for their own good" and for the good of the stakeholders who find it profitable to invest enough to dominate the standards-development process. Within the broader software engineering community, the Agile Manifesto reflected exactly the same irritation with exactly the same mix of mythology, self-interest, and pious ignorance. It is unfortunate that ISO appears to have learned nothing from that rebellion. -- Cem Kaner, J.D., Ph.D., Professor of Software Engineering

My apologies for the rambling novel, but I can't help myself here. As with any "standard" that is created, one of the worst end results that may occur is to have an entity unquestioningly adopt said standard as "best practice". Humans, by nature, tend to shy away from both responsibility and effort. Setting this "standard", especially without consensus of the software testing community at large, as has been claimed by the individuals promoting 29119, could actually damage the software testing industry as a whole. Management within larger organizations who are often concerned with being associated with ISO will not hesitate to embrace the standard for no other reason than to add another stamp of approval in their marketing literature. Their doing so will likely constrain their testing activities to a document, relieving their employees of responsibility and effort, of critical thinking required to adapt testing process and strategy to the company's business practices and the product's and customers' quality requirements. Who wins in this scenario? The tester certification industry who charges a fee to "train" testers within two working days to be qualified to follow the "standard". Cem, thank you for starting this petition. So we have recognized industry experts such as Cem Kaner and James Bach, among many others, who disagree with adopting the standard. Google either of those names and you will get an idea of their influence in and level of contribution to the software testing community. Google Stuart Reid, the "convener of the standard since its inception in 2007". I gave up looking for a reference to him that wasn't somebody else's Facebook page or artists or children's book authors. Google his name and James Bach together? There are some fun reads. So, who is Dr. Stuart Reid? As best as I can tell, he's the CTO of TSG, a software testing consultancy that is bedded with the ISTQB, Dr. Reid being the founder and former president of this software testing cert

Dear ISO, Since 2006, when he attended the first CAST conference, Stuart Reid has been aware of the strong opposition by the AST and the Context-Driven community to the very idea of standardizing testing. He and his cohorts have made no effort to reach out to this community-- which is dedicated to studying and advancing the art and craft of testing, and which has received worldwide recognition for doing so. It is against your policies and your ethics to allow a standardization effort to proceed in the face of determined and principled opposition. Please stop this farce and live up to your creed. Regardless of what you do, your "standard" will not succeed. The question is how much ISO will be tarnished by this naked attempt to take over our craft. -- James Bach, Author of Lessons Learned in Software Testing

I worked full time over a 3.5 year period as one of the primary authors of the Rational Unified Process (RUP). One of my main focus areas was the Testing discipline. If there is one truth I came to know during that time, it is that standardising software process and practice in a generalised way to suit every specific context that may eventuate in the wild is an enormous and in my view intractable challenge. In my 25 year plus career, I am yet to find a software testing process, method, framework or documentation standard that warrants being standardised in any generalised way. There is simply too much diversity to make that an undertaking of value for the general community at large: such standards best serve small, isolated groups in specific contexts. To frame my comment, I should note that RUP was an attempt at capturing a smorgasbord of good guidance on software development process and practices, and enable that to be configured into an actionable process, suitable for and tailor able to be used in a broad range of software project contexts. The Rational Software organisation was in the rare and privileged position of having strong relationships with an extremely diverse set of customers, operating in a vast number of contexts. In my 25+ years in software development, the 7 years I spent working with Rational Software was the most regular and prolonged exposure to such a diverse range of software development situations: mil-aerospace, government, education, finance, telco, manufacturing, retail, dot com start ups, open-source community groups, embedded software, web software, small 3-person teams up to many hundreds of staff, teams from every highly-populated continent, and from various cultures. Given Rational's visibility of the immense range of contexts that software projects operate in, it became very clear to me that for every situation in which good guidance could be offered, there was always at least one context in which that guidance was