Please sign the Petition to Stop ISO 29119

Please sign this petition:

I rarely rant about software engineering standards because it seems like a waste of time. Many of the participants in the software engineering standards movement are fine people who I respect. Some of them I call friends, or would be happy to have as friends. But several groups stand to benefit from being able to claim that they are following, selling, or training a collection of processes that are simplistic and easily described, even if they are ineffective and enormously wasteful. These groups can afford to invest a lot of money dominating the standards committees that, in turn, have come to serve their interests. They can also afford to invest a lot in public relations to promote the perceived legitimacy of those committees’ work.

My experiences with the IEEE software engineering standards (which are the main basis for these ISO standards), began when I first came to Silicon Valley in 1983. They have been uniformly negative. I finally left IEEE in 2010 or 2011, at that point a Senior Member who had been recognized by IEEE for my work on their standards and even been appointed by Congress to the United States’ Election Assistance Commission’s Technical Guidelines Development Committee at IEEE’s request. (TGDC wrote technical standards and much of its work was guided by an IEEE standard that I had worked on.) I left IEEE as a protest against a software engineering standards process that I see as a closed vehicle that serves the interests of a relatively small portion of the software engineering community.

Context-driven testing developed as the antithesis of what is being pushed through ISO. They represent opposite points of view.

Standards are political documents and sometimes legal ones. The existence of a standard makes it easier for a court (or a regulator) to rule that the standard-approved approach is the professionally correct one, and the non-approved approaches (or the ones that conflict with the approved one) are professionally incorrect and therefore improper. The imposition of a standard that imposes practices and views on a community that would not otherwise agree to them, is a political power play.

If ISO 29119 is adopted and then broadly accepted as a legitimate description of good professional practice in software testing, then context-driven testing will be an example of something you should not do, a way of thinking you should avoid.

I don’t think it will do much good to sign a petition against ISO 29119, but I would rather say that I protested against it than simply accept its consequences in silence.

I recommend that you do the same.

9 thoughts on “Please sign the Petition to Stop ISO 29119

  1. Old school thinking that doesn’t support a context-driven agile approach is a backward step. Won’t help me one little bit.

  2. Thanks Cem, I understand your points, and in part agree, but I have taken the tacit of trying to change standards from the inside. I can hope people like yourself will be a critic from the outside of standards to help drive people like myself to work to change them.

  3. As a tester for the past 20 years, I have found things that worked for me, things that I keep on doing, things that I teach to others. But I would never consider those as a standard to make everybody else do as part of their software testing. I wouldn’t even want to make myself do them.

  4. Greetings Cem,

    Thanks for your insight on the ISO29119 issue, it has helped me in understanding the opposition a little better. To tell you the truth, yours is the first article I read which includes a rationale that is not based on hatred, defamation or otherwise unsubstantiated claims against the ISO. It is truly an eye opener. Thanks for that as I was mainly turned off by the opposition because of the tactics that were / are being used to oppose it.

    I do have a question regarding this statement:
    “The existence of a standard makes it easier for a court (or a regulator) to rule that the standard-approved approach is the professionally correct one, and the non-approved approaches (or the ones that conflict with the approved one) are professionally incorrect and therefore improper.”

    The above does alarm me and I was wondering if you could give an example / situation under which a court would issue such a ruling that would affect all of us testers at large.

    Thanks again for taking the time and for your perspective on the Context Driven approach.


    I wrote a paper on “Software Negligence and Testing Coverage” that you can find at This lays out the general rules for negligence.

    Another paper, “Computer Malpractice” discusses the idea of holding service providers liable for malpractice liability. It’s at Malpractice involves professional negligence–a failure of a professional to provide services that live up to the ordinary and reasonable practices of that profession. Liability for professional negligence ensues when there is some kind of harm, including economic harm, resulting from bad professional services.

    So, for example, the site, defines negligence this way:

    Ordinary negligence exists when a party (i) owes a non-contractual duty of “reasonable care” to another party, such as a duty to comply with professional standards in an industry, (ii) disregards the duty, (iii) causes damage or injury to the rights or person of the other party and (iv) such damages were proximately caused by the breach of the duty. In outsourcing, this issue arises from the contractual provision that the service provider will perform in accordance with “industry standards” or other “professional standards.” This addition of a negligence standard to the services contract imposes a risk of additional liability for the service provider but may be appropriate where the service provider is actually marketing or performing in an “industry standard” or “professional-level” quality of service.

    The Crowell & Moring law firm published a relevant white paper on this, with several descriptions of court cases, “Industry Standards as a Source of Liability for Trade Associations and Association Members” (Timothy Biddle, Edward Green, Richard Mannix, & Scott Winkelman, 2002)

    Suppose you are involved in the development of a software product as an independent service provider (such as a software quality consultant). Suppose you give horrible advice and that as a result, your client releases bad software that costs people lots of money. They sue your client. They sue you. Your client sues you. They all scream “malpractice” at you.

    Two of the major issues in this litigation will be

    1. Are you a “professional” (or is the type of service you provide the type that we should consider a “professional” service)?
    2. Did you provide services (such as guidance) that meets the ordinary expectations of competence in your profession?

    An ISO standard goes a long way toward establishing what the industry thinks is the minimum level of acceptable practice. If your recommendations do not agree with the recommendations that would have been made by someone well-versed in the standard, the people suing you will have an easier time of arguing that your advice was incompetent and you should be held accountable. A comprehensive standard, from an organization with the very high credibility of ISO, will be very compelling evidence to a judge and jury that the responsible, reputable members of the profession have considered How Things Should Be Done and have set out the widely-accepted opinion. Someone arguing that the ISO standards writers are full of beans and that their standardized guidance is self-serving nonsense might be entirely correct, but it would be difficult to convince a judge or jury of that.

    My Computer Malpractice paper was focused on the other issue, whether software developers should be considered as “professionals.” The rules for that are subject to judgment. Basically, the more you look like a professional, the more likely it is that a judge will hold you to the same level accountability as someone who is a member of a traditional, licensed profession. A variety of factors are involved in assessing whether a type of work (the work itself, or the work plus how it was marketed) should be treated as “professional”.

    • The existence of a broadly accepted industry standard that comprehensively addresses this type of service (such as a standard that lays out rules for competent software testing in all contexts) would be influential.
    • An example of another factor would be whether you hold a certification from a professional society that attests to your competence, especially a certification that involves disciplinary rules under which you could be decertified or otherwise punished for incompetent or unethical conduct.

    The specific rules vary from country to country. In addition, my understanding is that several cases decided by American arbitrators (private judges, rather than State-appointed judges) have held service providers accountable for malpractice under conditions that probably would not have resulted in a malpractice verdict in a traditional courtroom. Fear of bad arbitration results is one of the key motivators for those software service professionals who carry malpractice insurance–American courts probably won’t hold them accountable for professional negligence but arbitration results are less predictable.

    Over time, our field has evolved to look more like a traditional profession. The IEEE has repeatedly proposed that software engineers should be a licensed profession. Some states (Texas, I think), have adopted this idea in principle though they have not yet created regulations around it. Some countries (Canada is an example, I think) have also picked up the idea in principle, though I think that no country yet has fully embraced the idea. But this type of thing evolves. The more that an industry looks as though it is imposing standards and certifications on itself, the more comfortable judges and legislators will be in deciding that the industry is really a professional-service industry that should be regulated in the traditional way.

    — Cem Kaner

  5. Pingback: Please sign the Petition to Stop ISO 29119

  6. Pingback: ISO 29119: Why is the Debate One-Sided?

Leave a Reply

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