29119

このページでは、ISO/IEC/IEEE 29119シリーズに関する論争についてまとめています。

翻訳は日本のテストコミュニティの有志によって行われています。私たちは、ISO/IEC/IEEE 29119シリーズについて技術的にフェアな理解と議論が日本で行われるために、翻訳を行いました。

あらゆる技術・手法・ツール・記法・規格・標準・法規は良い点と悪い点を備えています。そのどちらかからも目を背けることなく、かつ両者を技術的にフェアに理解することによって、技術・手法・ツール・記法・規格・標準・法規は適切に活用することができます。

私たちは日本の組織が、ISO/IEC/IEEE 29119シリーズが自組織に適しているかをきちんと判断し、導入すべきところと導入すべきでないところを見分け、盲目的に従うのではなく導入の目的にかなうように導入することを望んでいます。この翻訳群が、その一助になれば幸いです。

29119

（訳注：このページは、Context-Driven-TestingのWebサイト（）に掲載されている"Please sign the Petition to Stop ISO 29119“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書は著者であるCem Kanerに翻訳および公開を許諾されています。翻訳はKazu Suzukiが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、qualab.jpの管理人であるYasuharu.Nishi@uec.ac.jpまでお知らせ下さい。）

Please sign this petition: http://www.ipetitions.com/petition/stop29119

この請願に署名をお願いします: http://www.ipetitions.com/petition/stop29119

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.

ソフトウェアエンジニアリングの標準について、わたしがわめき立てることなどめったにない。時間の無駄としか思えないからだ。ソフトウェアエンジニアリングの標準化の活動に参画する人の多くは立派な人だし、尊敬もしている。その中には友人と呼べる人もいれば、友人になれたらと思える人もいる。
しかし一部のグループは、単純化されて簡単に説明できるようなプロセスの集合に自分たちが従っているとか、そのプロセスを売り込んだり研修を行ったりしていると主張できるようになることで利益を得る立場にある。たとえそのプロセスに大した効果がなく、きわめて無駄なものであったとしてもだ。そういったグループは、標準化委員会を支配して自分たちが利益を得られるように潤沢な金を投資する余裕がある。また、委員会の作業が正統なものと広く認められるように、PRに多くを投資することもできるのだ。

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.

IEEEのソフトウェアエンジニアリングの標準（ISO標準の主な土台でもある）に関するわたしの経験は、初めてシリコンバレーに来た1983年に始まった。その経験は一様にネガティブなものであり、わたしは2010年か2011年についにIEEEを去った。その時点でわたしは、IEEEの標準に対する仕事を認められたシニアメンバーであり、またIEEEの要請により、米国の選挙支援委員会の技術ガイドライン開発委員会（TGDC）の委員として、議会から任命されていた（TGDCは技術的な標準を書いたが、その作業の大半は、わたしが携わったIEEEの標準に方向づけられたものである）。わたしから見て、ソフトウェアエンジニアリングの標準化のプロセスはクローズドな進め方であり、それがもたらす利益を受けるのは、ソフトウェアエンジニアリングのコミュニティの比較的小さなグループである。そのようなプロセスへの抵抗として、わたしはIEEEを去った。

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

コンテキスト駆動テスティングは、ISOを通じて推進されてきたもののアンチテーゼとして開発された。両者はまったく逆の立場を代表している。

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.

もしISO 29119が採択され、それがソフトウェアテスティングに関する専門的で適切なプラクティスの正統な説明であると広く受け入れられれば、コンテキスト駆動テスティングは、行うべきでないことの例、避けるべき考え方ということになってしまうだろう。

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.

ISO 29119に対する請願に署名することでどうにかなるとは思わない。しかし、わたしは単に黙って結果を受け入れるのではなく、それに抵抗したのだと言いたい。

I recommend that you do the same.

あなたも同じようにすることをお勧めする。

29119

（訳注：このページは、DevelopSenseのWebサイト（http://www.developsense.com/）に掲載されている"Blog: Frequently-Asked Questions About the 29119 Controversy“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書は著者であるMichael Boltonに翻訳および公開を許諾されています。翻訳はKazu Suzukiが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、qualab.jpの管理人であるYasuharu.Nishi@uec.ac.jpまでお知らせ下さい。）

This is a first stab at a frequently-asked questions list about the movement to stop ISO 29119. Here I speak for myself, and not for the community. If you see “we”, it refers to my perception of the community at large, but not necessarily to the whole community; your mileage may vary. There is plenty of discussion in the community; Huib Schoots is curating a collection of resources on the controversy. If you’ve got a different perception or a different opinion, please share it and let me know. Meanwhile, I hasten to point out that absolutely everyone is welcome and encouraged to share my opinions.

　この記事は、「stop ISO 29119」活動におけるFAQのリストの最初の試みである。自分のためのものであり、コミュニティに向けたものではない。「we」という場合、コミュニティ一般に対するわたしの認識について述べているのであって、必ずしもコミュニティ全体に対するものではない。「個人の感想です」ということだ。
コミュニティにおいて、多くのディスカッションがなされている。Huib Schoots氏が、この問題における資料を一覧として選別してくれている。あなたが違う考え方、違う意見を持っているのであれば、それを共有し、わたしに教えてほしい。一方で、みなさんにぜひ、わたしの意見を広めてほしいと付け加えておこう。

Q. Why bother with a community attack on ISO 29119? Isn’t it irrelevant to most testers? And why now? / なぜコミュニティはISO 29119に対する批判などに関わっているのか。ほとんどのテスターには関係のないことでは？ それに、なぜ今なのか。

To start with, we believe that ISO 29119 is irrelevant to all testers, in the sense that it seems to be an overstructured process model, focused on relentless, ponderous, wasteful bureaucracy and paperwork, with negligible content on actual testing. If your organization is in the business of producing pointless documentation, so be it, but that’s not what we call testing. The approaches suggested by 29119 might be useful to people who are more interested in ass coverage than in test coverage.

　まず第一にわたしたちは、ISO 29119が過度に構造化されたプロセスモデルであり、実際のテスティングにおいては取るに足らない内容とともに、過酷で、重く、無駄な官僚主義と書類仕事にフォーカスしているように見えるという意味で、すべてのテスターにとってこの標準は見当違いなものであると考える。あなたの組織が的外れなドキュメント作りを仕事にしているのであれば好きにすればよいが、わたしたちはそれをテスティングとは呼ばない。29119で提示しているアプローチは、テストカバレッジではなく、人間の許可のカバレッジ（訳注　ass coverage: 周囲のステークホルダーにどれだけ承認をもらえたかを気にする文化への皮肉と思われる）に興味がある者には有用かもしれない。

Originators and supporters of the petition are trying to establish a pattern of opposition to the standard. This becomes important when lawyers or auditors ask “Why didn’t you follow ‘an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation’?” Loud voices of opposition—not only to the standard, but also to the process by which it was created and by which it will be marketed—will help to show that the suggestion of “international agreement” is meaningless; that the standard misrepresents testing as many prominent testers see it; that the standard is overly complex and opaque; that it is both too vague here and too specific there to be useful in “any” organisation; and that radically different contexts for testing—quite appropriately—require radically different approaches for testing.

　この請願への起案者・賛同者は、ISO 29119への反対意見のパターンを確立しようとしている。これは、弁護士や監査官に「なぜあなたは、いかなるソフトウェア開発のライフサイクルにも、組織にも適用できる『国際的に合意されたソフトウェアテスティングに関する標準一式』に従わなかったのか」と問われた時に重要になってくる。声の大きな反対意見ーーー標準への反対であるだけでなく、それが作成されたプロセス、そしてそれが売り込まれるプロセスへの反対でもあるーーーは、「国際的な合意」という言葉に何の意味もないこと、その標準はテスティングを不正確に伝えていると多くの卓越したテスターが考えていること、過度に複雑で不可解であること、曖昧すぎる部分もあれば、「いかなる」組織にとっても有用であるというには細かすぎる部分もあるということ、そしてコンテキストが根本的に違えば、当然ながらテスティングに求められるアプローチも根本的に異なるということを示す助けになるだろう。

As to the “why now” question, there’s another reason for the groundswell that I think we’re discovering as we go: over the years, in fits and starts, the context-driven community has become much larger and more capable of acting like a community. And that despite the fact that people who aspire to be fiercely independent thinkers can be a fairly fractious bunch. A community that welcomes serious disagreement will have serious disagreements, and there have been some. Yet it seems that, every now and then, there are some things that are just odious enough to unite us. Personally, I’m treating this as a trial run and a learning experience to prepare for something seriously important.

　「なぜ今なのか」という問いには、別の理由がある。わたしたちが見出しつつある大きなうねりのためだ。何年にも渡って、次第にではあるが、コンテキスト駆動のコミュニティはずっと大きくなり、コミュニティらしくふるまうこともできるようになってきた。他に依存せず考えぬこうとする者たちは時として、非常に気難しい集団になりかねないという現実にも関わらずである。
深刻な意見の不一致を歓迎するコミュニティには、深刻な意見の不一致が生まれるもので、実際わたしたちにもいくつかの不一致はある。しかしわたしたちを団結させるほど不愉快なものが、時として現れるのだ。個人的には、そういったものは試運転のようなものであり、非常に重要なもののために備えて学ぶべき経験であると考えている。

Q. The promoters of the standard insist that it’s not mandatory, so what’s the fuss? / 標準の推進者は、標準が強制のものではないと言っているのに、なぜこのように騒ぎ立てるのか。

The promoters of the standard who say that the standard is not mandatory are being disingenuous. They are well aware of this idea:

　この標準が強制のものではないと言っている推進者は、誠実ではない。彼らは次のようなことがよくわかっているのだ：

“Still another classification scheme distinguishes between voluntary standards, which by themselves impose no obligations regarding use, and mandatory standards. A mandatory standard is generally published as part of a code, rule or regulation by a regulatory government body and imposes an obligation on specified parties to conform to it. However, the distinction between these two categories may be lost when voluntary consensus standards are referenced in government regulations, effectively making them mandatory standards.”
(Source: http://www.nist.gov/standardsgov/definestandards.cfm)

　使用するにあたって、それ自体は何ら義務を課さない任意の標準と、強制の標準を区別する方法には、別の分け方もある。強制の標準は通常、規制を行う行政機関によって規定・ルール・規制の一部として発行され、その標準に準拠する義務を特定の集団に課す。しかし、行政機関が規制の中で参照すると、任意の標準は強制の標準になり、2つのカテゴリーの区別がなくなることがある。
(引用もよ: http://www.nist.gov/standardsgov/definestandards.cfm)

The 29119 promoters begin by using appeal to authority (in this case, the reputation of ISO) to declare a standard. If it so happens that a regulator or bureaucrat, uninformed about testing, happens upon “an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation” and refers to them in government regulations, well, then, so much the better for aspiring rent-seekers who might have been involved in drafting the standard.

　29119の推進者は、権威（この場合、ISOの評判）に訴えることで、標準を宣言し始めている。もし規制者や官僚が、テスティングを均一なものにしようとして「いかなるソフトウェア開発のライフサイクルにも、組織にも適用できる、国際的に合意されたソフトウェアテスティングに関する標準一式」を見つけ、行政の規制の中でそれに言及すれば、標準の策定に参加してレントシーカー（訳注：公的機関による規制などを利用として利益を得ようとする者を指す）になろうとしている者には好都合だろう。

Q. If ISO 29119 is so terrible, won’t it disappear under its own weight? / ISO 29119がそんなにひどいものなら、それ自身の重みで消えてしまうのでは？

Yes, it probably will in most places. But for a while, some organizations (including public ones; your tax dollars at work, remember) will dally with it at great cost—including the easily foreseeable costs of unnecessary compliance, goal displacement, misrepresentation of testing, and yet another round of marketing of bogus certifications, whereby rent-seekers obtain an opportunity to pick the pockets of the naïve and the cynical.

　たぶん多くのところでそうなるだろう。しかししばらくの間は、莫大なコストをかけてこの標準にかかずらう組織（公的機関も含む。そこでの仕事にはあなたの税金が使われていることを思い出してほしい）もあるだろう。必要もないものへの準拠、目標の喪失、テスティングに対する誤った説明、さらにはいんちきな認証といったコストは容易に想像できる。一方でレントシーカーは、世間知らずや皮肉屋から金を巻き上げるチャンスを得るというわけだ。

Q. Aren’t you just griping because you’re worried that your non-standard approach to testing will put you out of business? / あなたは、標準にそぐわない自分のテスティングアプローチではビジネスにならなくなることを心配しているだけではないか？

Here’s how I answered this question on one blog (with a couple of minor edits for typos and clarity):

　この質問にはあるブログで答えているので紹介しよう。（誤記の修正と論旨を明確にするために、いくつか小さい修正をいれている）

“In one sense, it won’t make any difference to my business if 29119-1, 29119-2, and 29119-3 are left to stand, and if 29119-4 and 29119-5 move from draft to accepted. Rapid Software Testing is about actual testing skills—exploration, experimentation, critical thinking, scientific thinking, articulate reporting, and so forth. That doesn’t compete with 29119, in the same kind of way that a fish restaurant doesn’t compete with the companies that make canned tuna. We object to people manipulating the market and the ISO standards development process to suggest to the wider world that canned tuna is the only food fit for people to eat. I discuss that here: http://www.developsense.com/blog/2014/08/rising-against-the-rent-seekers/

　「ある意味で、29119-1、29119-2、29119-3がそのままであろうと、29119-4や29119-5がドラフトから採択になろうと、わたしのビジネスには何の違いもない。「高速ソフトウェアテスティング」は、現実におけるテスティング技術だ。探索、実験、クリティカルシンキング、科学的な考え方、明確なレポートなどなど。魚料理のレストランがツナ缶を作る企業と競合しないように、わたしたちのアプローチは29119と競合しない。わたしたちは、「ツナ缶は人々が食べるにふさわしい唯一の食べ物だ」と世の中に広く主張するために、市場やISOの標準の開発プロセスを操ろうとする者たちに反対しているのだ。このことについては以下で議論している。
http://www.developsense.com/blog/2014/08/rising-against-the-rent-seekers/

“In another sense, 29119 could be fantastic for my business. It would offer me a way to extend the brand: how to do excellent, cost-effective testing that stands up to scrutiny in contexts where some bureaucrat, a long way away from the development project, was fooled into believing that 29119 was important. At the moment, I’m happy to refer that kind of business to colleagues of mine, but I suspect that it would be something of a gold mine for me. Yet still I oppose 29119, because what’s in my interest may not be in the interests of my clients and of society at large.

　「またある意味で、29119はわたしのビジネスにとって素晴らしいものになるかもしれない。名声を広める道をもたらしてくれる可能性もある。開発プロジェクトから遠く離れたところにいる官僚たちが29119が重要なものだと信じるようだまされている状況で、素晴らしく、コスト効果があり、精査にも耐えうるテスティングを行うにはどうすればいいか、といったものだ。今のところ、この種の仕事を同僚に頼むことはやぶさかではないが、わたしにとって宝の山なのではないかと思う。それでもやはり、わたしは29119には反対だ。わたしの利益が必ずしも、わたしの顧客の、あるいは広く社会の利益であるとは限らないからだ。

“Let me be specific: There are existing standards for medical devices, for avionics, and the like. Those standards matter, and many of them are concise and well-written, and were created by genuine collaboration among interested parties. Testers who are working on medical devices or on avionics software have a limited number of minutes in the working day. As someone who flies a lot, and as someone who is likely to require the help of medical devices in the foreseeable future, I would prefer that those testers spend as many minutes as humanly possible actually investigating the software, rather than complying (authentically, pathetically, or maliciously) to an unnecessary standard for process modeling, documentation, and strategising (a standard for developing a strategy—imagine that!).”

　「もう少し具体的に言おう。医療機器、航空といったものにはすでに規格がある。これらは重要なものであり、その多くは簡潔でうまく記述されているし、関係する団体の誠実な協働によって作り上げられている。医療機器や航空のソフトウェア開発で働いているテスターは、平日には限られた時間しかない。たくさん飛行機を利用する者として、また遠くない将来に医療機器の助けが必要になるであろう者として、テスターにはできる限り多くの時間をソフトウェアを調べることに使ってもらいたい。プロセスモデリングのための不必要な標準、ドキュメンテーション、戦略作り（戦略を作るための標準・・・想像できるか？）のための不必要な標準なんかを（正しい形にせよ、痛ましいやり方にせよ、あるいは悪意をもってにせよ）守ろうとするよりも。

Q. You just don’t like standards. Isn’t that it? / あなたは単に標準が嫌いなだけではないのか？

Nope. I love standards when they’re used appropriately.

　そうではない。適切に使われるのであれば、標準は大好きだ。

As I emphasized in a 2011 PNSQC presentation called “Standards and Deviations“, it is possible and often desirable to describe and standardize widgets—tangible, physical things that have quantifiably measurable attributes, and that must interface, interact, or fit with other things. Thank goodness for standardized screws and screwdrivers, CDs, and SATA hard drives! Bravo to the EU for mandating that power supplies for smartphones standardize on USB! Yet even with widgets, there are issues related to the tension between standards and an advancing state of the art. Here’s one of the best-ever articles on problems with standards: Joel Spolsky on Martian Headsets.

　2011年のPNSQCにおいて「標準と逸脱」というプレゼンテーションで協調したように、手で触れられて、定量的に測定可能な属性を持つ物理的なものであれば、そしてそれが他のものと接続されたり、相互作用したり、他の物とうまく合う必要があるものであれば、標準化することは可能だし、望ましいことでもある。

It is more difficult and to describe processes, since the description is, by necessity, a model of the process. It’s difficult for many people to avoid reifying the model—that is, to avoid treating the model—idea-stuff—as though it were a thing. For an example of reification of testing, take a few moments to reflect on the notion of representing testing work in terms of test cases; then read “Test Cases Are Not Testing: Toward a Culture of Test Performance” by James Bach & Aaron Hodder. More generally, 29119’s focus on the artifacts and the process model displace and de-centre the most important part of any testing effort: the skill set and the mindset of the individual tester.

　プロセスを説明しようとすると必然的に、プロセスのモデルを説明することになるので、もっと難しい。多くの人にとって、モデルを具体化して考えないようにする、つまり、イデアたるそのモデルを、モノであるかのように扱わないでおくことは難しい。テスティングを具体化する例として、「テストケース」という用語でテスティングの作業を表現するということについて、少しの時間考えてみてほしい。それから、James BachとAaron Hodderの『テストケースはテスティングではない。テストというパフォーマンスという文化に向かって』を読んでほしい。より一般的に言うと、29119は中間成果物やプロセスモデルに注目するあまり、テスティングの作業においてもっとも重要な部分をどこか隅っこに追いやってしまっている。つまり、個々のテスターのスキルセットやマインドセットというものだ。

Q. Do you really believe that ISO 29119 can be stopped? / あなたは本当に、ISO 29119を止められると思っているのか？

No, of course we don’t. Curtis Stuehrenberg puts it perfectly in a discussion on LinkedIn: “The petition is not about stopping the publication any more than an anti-war march is about a reasonable expectation of ending a war through a parade. The point of the petition and the general chatter is to make sure at least some people hear there is a significant portion of the testing community who was not represented and who espouse different viewpoints and practices for software testing as a professional discipline.” If we can’t get the standard stopped by the ISO’s mechanisms, at least we can show that there is an absence of consensus outside of the 29119 working groups.

　いや、もちろん思っていない。Curtis Stuehrenbergが、LinkedInでの議論の中でそれを完璧に表現している。「この請願は、発行と止めようとするものではない。反戦マーチが、パレードを通して戦争が終わることをほどほどの期待するのと同じだ。この嘆願ややりとりにおいて大事なことは、ソフトウェアテスティングにおいて、プロフェッショナルな規律として別の考え方ややり方を支持する大きな集まりがあり、推進者の中にその代表者はいないということを、少なくとも一部の人々が耳にしたということをはっきりさせることなのだ」。もしISOの構造により規格を止められないとしても、わたしたちは少なくとも、29119のワーキンググループの外部においてはコンセンサスが得られていないことを示すことができるのだ。

Q. The standard has been in development for the last seven years; why have you waited so long? / この規格は7年に渡って進めれれている。なぜこんなに待っていたのか。

Some of us haven’t been waiting. For example, I gave this presentation in 2011. Some of us have been busy objecting to certification schemes. (There’s only so much rent-seeking one can oppose at once.) Several of us have argued at length and in public with some of the more prominent figures promoting the standard at conferences. They sometimes seem not to understand our objections. However, as Upton Sinclair said, “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!” (http://en.wikiquote.org/wiki/Upton_Sinclair) Whether through terrible argumentation or deliberate guile, the responses in those discussions usually took the form of non-sequiturs: “The standard is optional; something is better than nothing; many people were involved; the perfect is the enemy of the good; we’re trying to help all those poor people who don’t know what to do.” The standards promoters should (and probably do) know that those statements would apply to any process model that any person or group could offer. Constructing bogus authority into the ISO, and then appealing to that authority, looks an awful lot like rent-seeking to me.

　誰もが待っていたわけではない。たとえばわたしは2011年にプレゼンテーションを行っている。認定のスキームへの反対に力を入れていた者もいる(一人の人間が一度に反対できるレントシーキングは限られているのだ）。カンファレンスなど公の場において長く、規格推進の大物と議論している者もいる。彼らは時に、わたしたちの反対を理解していないように見えるが、Upton Sinclairが言うように、「誰かに何かを理解してもらうのは難しい。彼がそれを理解していないがゆえに給料をもらえているとしたら」（http://en.wikiquote.org/wiki/Upton_Sinclair）。ひどい論争を通してであろうと、意図的な悪知恵であろうと、その議論における反応は、不合理な結論という形ととる。「規格は任意のものだ。どんなものであれ、ないよりはましだ。多くの人がそれに関わった。完璧は善の敵だ。わたしたちは、何をすればいいかわからない可哀想な人たちを助けようとしているのだ」。規格の推進者は、こういった主張が、いかなる人間・グループによって提案されたいかなるプロセスモデルにも当てはまることだということに気付くべきだ（し、おそらく気づいているのだろう）。ISOにいんちきな権威を作り出し、その権威に訴えることは、わたしには本当にレントシーキングに見える。

there has been begged
Moreover, it strains believe that the standard has undergone serious development when some of the basic models (for example, 29119’s model for the test planning process) have gone essentially unchanged over four years—a period that included the rise of smartphones and mobile technology, the aftermath of the financial crisis, and the emergence of tablet computing. Testing in an Agile context reportedly garners little more than a few hand-waving references. I can’t say I’m surprised that testing and checking don’t appear on 29119’s radar either.

　さらに、この規格はずいぶんと進んだが、基本的なモデル（たとえば29119のテスト計画プロセス）には4年以上の間、本質的な変更がなかった。この時期には、スマートフォンやモバイルテクノロジーの勃興や金融危機の直後、そしてタブレットコンピューティングの登場を含まれる。聞くところによると、アジャイルのコンテキストにおけるテスティングについては、お茶を濁す程度の言及しかないとのことだ。「テスティングとチェッキング」が、29119のレーダーには引っかからないということには、驚きもしなかった。

Q. Why didn’t you object using the formal process set up by ISO? / あなたはなぜ、ISOの正式なプロセスにのっとって反対しないのか。

As James Bach points out, the real question there has been begged: why should the craft have to defend itself against a standards process that is set up to favour the determined and the well-funded? ISO is a commercial organization; not an organ of the United Nations, emanating from elected representative governments; not an academic institution; not a representative group of practitioners; not ordained by any deity. The burden is on ISO to show the relevance of the standard, even under its own terms. Simon Morley deconstructs that.

　James Bachが指摘するように、本当に問われているのは以下のことだ：権力のある者、金を持っている者に有利に働くように定められた標準に対し、なぜ技術者の方が抗弁しなければならないのか。ISOは営利機関である。政府に選ばれた代表者から成る国連の組織ではないし、学術団体でもない。実務家の代表でもない。何らかの神格に定められたものでもないのだ。規格の妥当性と、自分たちの言葉で説明することが責務があるのは、ISOの方である。Simon Morleyがそれを分析してくれている。

Q. Wouldn’t it be good to have an international common language for software testing? / ソフトウェアテスティングについて、国際的な共通言語ができるのはいいことではないか？

Great idea! In fact, it would be good to have an international common language for everything. And in order to be truly international and to represent the majority of people in the world, let’s make that language Mandarin, or Hindi.

　いい考えだ！ 事実、どんなものにでも国際的な共通言語があるといいだろう。そしてその共通言語を真に国際的なものにし、世界の多数派を代表するものにするために、その言語を中国標準語かヒンズー語にしよう。

There are many arguments to show that a common language for software testing is neither desirable nor possible. I’ve blogged about a few of them, and I’ve done that more than once.

　多くの議論が、ソフトウェアテスティングに関する共通言語は望ましいものでもなく、また実現できるものでもないということを示している。わたしもいくつかを、一度ならずブログに書いている。

Q. Why are you always against stuff? Don’t you want to be for something? / なぜあなたはいつも、何かに反対しているのか。何かに賛成したくはないのか。

You don’t have to be for something to be against something that’s odious. But as a matter of fact, I am for something that is more important than any standard: freedom and responsibility for the quality of my work (as I hope all testers are for freedom and responsibility for the quality of their own work). That includes the responsibility to make my work capable, credible, open to scrutiny, and as cost-effective as possible. I must be responsible to my clients, to my craft, and to society as a whole. In my view, those responsibilities do not and should not include compliance with unnecessary, time-consuming, unrepresentative standards created by self-appointed documentation and process-model enthusiasts.

　不愉快なものに反対するために、何かに賛成する必要はない。とはいえ実際は、標準なんかよりもっと大事なものに賛成してはいるのだ。自分の仕事の質に対する自由と責任である（同様に、すべてのテスターが自身の仕事の質に対する自由と責任に賛成してほしい）。それは、自分の仕事を有効で、信頼できるものであり、批判に対して開かれており、そしてできる限り費用効果のあるものにする責任を含む。わたしは自分の顧客、自分の職業、そして全体としては社会に対しても責任を持たなければならない。わたしの考えでは、自称「ドキュメンテーションとプロセスモデルの愛好者」によって作られた、不必要で時間ばかり食う、誰を代表するわけでもない標準に準拠することは、責任に含まれていないし、含まれるべきでもない。

Some other things I’m for: the premises of Rapid Software Testing; the Rapid Testing framework; studying the structures of exploratory testing; the Heuristic Test Strategy Model; a set of commitments for testers to make to their clients; practicing the skill of test framing; excellent reporting; and a host of other things. This is unrepresentative of the wider testing community… so I bet you’re glad that compliance with standards set by James and me is voluntary. In fact, compliance with our standards requires you to invent testing for yourself; to adopt standards that help; and to resist the ones that don’t, including ours. But if you find something else that works for you, tell us. Tell everybody.

　わたしが賛成するのはもっと別のもだ。高速ソフトウェア開発の前提条件、高速テスティングフレームワーク、探索的テストの構造を学ぶこと、ヒューリスティックなテスト戦略モデル、顧客に対してテスターが持つべきコミットメント、テスト立案のスキルの修練、他たくさんのものだ。これはテストのコミュニティを広く代表するものではないので、Jamesとわたしが定めた標準に従うかどうかは任意だということは、歓迎されるだろう。事実、わたしたちの標準に従うということは、あなた自身のためにテスティングを発明することを求められる。そのためになる標準には従い、（わたしたちの標準を含めて）そうでないものには抵抗する。あなたのためになる何か別のものを見つけたなら、わたしたちに教えてほしい。みんなに教えてほしい。

Q. What about the poor people who need guidance on how to test? / どうテストすればいいかのガイドを必要とする可哀想な人たちについてはどうする？

My (free) offerings to those poor people include those just above. Those poor people are welcome to use these suggestions and to investigate the alternatives that anyone else offers. That may be harder than referring to an ISO standard and appealing to its authority. (It may be considerably easier, too.) But my first piece of guidance on how to test is this: learn about testing, and learn how to test, through study and practice. I argue that ISO 29119 will not help you with that.

　そのような人たちへのわたしの（無償の）提案には、上に挙げたようなものも含まれている。これらぜひ使ってほしいし、他の人が考えた別の代替案についても調べてみてほしい。ISOの標準に参照し、権威に訴えるするよりもずっと難しいかもしれない（ずっと簡単かもしれないが）。ただ、「どのようにテストするか」という質問に対してはまず、「学習と実践を通してテスティングについて学び、どうテストするかを学ぼう」とアドバイスしたい。ISO 29119はその手助けにはならないと主張したい。

Q. Okay, despite the Quixotic nature of the petition, I’m convinced. Where do I sign? / わかった、この請願は非現実的なものではあるが、納得した。どこで署名すればいいのか。

Go to http://www.ipetitions.com/petition/stop29119. And thank you.

　http://www.ipetitions.com/petition/stop29119を訪れてほしい。感謝する。

29119

（訳注：このページは、uTestのWebサイト（http://www.utest.com/）に掲載されている"ISO 29119: Why is the Debate One-Sided?“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書は著者であるJames Christieに翻訳および公開を許諾されています。翻訳はgoyoki@gmail.comが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、qualab.jpの管理人であるYasuharu.Nishi@uec.ac.jpまでお知らせ下さい。）

In August, the Stop 29119 campaign and petition kicked off at CAST 2014 in New York. In September, I wrote on the uTest Blog about why the new ISO/IEC/IEEE 29119 software testing standards are dangerous to the software testing community and good testing.

8月、ニューヨークでのCAST2014において、Stop 29119のキャンペーンと請願活動が開始された。
9月には、ソフトウェアテストのコミュニティや良いテストにとって、ISO/IEC/IEEE 29119の新しいソフトウェアテスト標準がなぜ危険なのかについて、私はuTest Blogに書いた。

I was amazed at the commotion ‘Stop 29119′ caused. It was the biggest talking point in testing in 2014. Over six months have passed, and it’s time to look back. What has actually happened?

Stop 29199の騒動が引き起こしたものに私は驚かされた。それは2014年のテストの話題として、最も大きなものとなった。騒動が始まって6ヶ月以上が経過したが、振り返るべきタイミングだ。これまで実際に何が起こっただろうか？

The remarkable answer is – very little. The Stop 29119 campaigners haven’t given up. There have been a steady stream of blogs and articles. However, there has been no real debate; the discussion has been almost entirely one-sided.

注目に値するものは、何も起こらなかった。
Stop 29119の活動者はとどまることがなかった。ブログや記事は途絶えることなく安定して出てきた。ただ現実でディベートが行われることなく、議論はほとんど一方的なものになった。

There has been only one response from ISO. In September, Dr. Stuart Reid, the convener of the working group that produced the standard, issued a statement attempting to rebut the arguments of Stop 29119. That was it. ISO then retreated into its bunker and ignored invitations to debate.

ISOからの反応は一つだけだった。9月に、Stuart Reid博士（標準を作成するワーキンググループのコンビナー）が、Stop 29119の主張への反論を試みる声明を出した。そしてISOは身を引いて、ディベートへの誘いを無視した。それだけだった。

Dr. Reid’s response was interesting, both in its content and the way it engaged with the arguments of Stop 29119. The Stop 29119 petition was initiated by the board of the International Society for Software Testing. ISST’s website had a link to the petition, and a long list of blogs and articles from highly credible testing experts criticizing ISO 29119. It is a basic rule of debate that one always tackles an opponent’s strongest points.

However, Dr. Reid ignored these authoritative arguments and responded to a series of points that he quoted from the comments on the petition site.
To be more accurate, Dr. Reid paraphrased a selection of the comments and criticisms from elsewhere, framing them in a way that made it easier to refute them. Some of these points were no more than strawmen.

Reid博士の反応は、内容、およびStop 29119の主張への噛み合い方の点で興味深いものだった。
Stop 29119の請願活動は、ISST(International Society for Software Testing)の委員会より始められたものだ。ISSTのウェブサイトでは請願へのリンクを設けた。またISO 29119を非難している、強く信頼できるテストの専門家たちのブログや記事の長大なリンクのリストも用意した。

ディベートならば、主張のうちもっとも強い論点に向き合うのが基本ルールだ。
ただReid博士は信頼し得るそれら引用を無視して、請願サイトのコメントから引用したいくつかの論点に応える形をとった。より厳密にいうと、Reid博士は、反対主張をどこからか持ってきた批判やコメントで言い換えて論破しやすいように仕立てあげた。それらのいくつかは藁人形論法での藁人形（Strawmen）でしかなかった。

So Cem Kaner argued that IEEE adopts 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… 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.”

例えばCem Kanerは「ソフトウェアエンジニアリングの限られたコミュニティの権益の得るための、閉鎖的なソフトウェアエンジニアリングの標準プロセスを、IEEEは適用しようとしている。同意しないコミュニティにその施行や見解を押し付ける標準の強制は、政治的パワープレイでしかない」と主張した。

Dr. Reid presented such arguments as “no one outside the Working Group is allowed to participate”and “the standards ‘movement’ is politicized and driven by big business to the exclusion of others.”

These arguments were then dismissed by stating that anyone can join the Working Group, which consists of people from all parts of the industry. Dr. Reid also emphasized that “consensus” applies only to those within the ISO process, failing to address the criticism that this excludes those who believe, with compelling evidence, that ISO-style standardization is inappropriate for testing.

するとReid博士は、そうした主張を「ワーキンググループには、外部からの参加は誰も許されていない」「標準化活動は、巨額な利益を生むビジネスを囲い込むために生み出され、駆動されている」という主張であると表現した。そしてそれらを「ワーキンググループはだれでも参加できることになっている。またワーキンググループは、産業のさまざまな人達で構成している」という主張で退けた。

また、信頼できる証拠を伴う「ISOスタイルの標準化がテストにとって不適切である、と考えている人々を除外している」という批判に対して、Reid博士は「ISOプロセスが生み出してきた標準にはコンセンサスを確保する」ことを強調するだけで、批判に対応しなかった。

These criticisms had been made forcefully for many years, in articles and at conferences, yet Dr. Reid blithely presented the strawman that “no one knew about the standards and the Working Group worked in isolation.” He then effortlessly demolished the argument that nobody was making.

こうした批判は複数年にわたって、記事やカンファレンスでも強く行われてきたものだ。しかし今でもRied博士はこれら批判を「誰も知らぬまま、標準やワーキンググループを密室で決めている」という藁人形に矮小化した。そして彼はだれも言ってもいないその声明に、楽々と反論した。

What about the content? There were concerns about how ISO 29119 deals with Agile and Exploratory Testing. For example, Rikard Edgren offered a critique arguing that the standards tried but failed to deal with Agile. Similarly, Huib Schoots argued that a close reading of the standards revealed that the writers didn’t understand exploratory testing at all.

内容についてはどうだろうか？そこではISO29119でのアジャイルや探索的テストの扱いについて懸念が存在する。例えば、Rikard Edgrenは「標準をアジャイルに適用しようとしたが失敗した」という批判を提示した。同じように、Huib Schootsは「標準の執筆者は探索的テストを何もわかっていないことが、標準を読むと明白だ」と主張した。

These are serious arguments that defenders of the standard must deal with if they are to appear credible. What was the ISO response?

これらは、標準の信頼を確保するために、標準の擁護者が対応すべき重大な主張だ。
ではISOの反応はどうだっただだろうか？

Dr. Reid reduced such concerns with bland and inaccurate statements that “the standards represent an old-fashioned view and do not address testing on agile projects” and ”the testing standards do not allow exploratory testing to be used.” Again, these were strawmen that he could dismiss easily.

Reid博士は、そういった懸念を「標準は時代遅れの見解に基づいており、アジャイルプロジェクトでのテストに対応していない」「テスト標準は探索的テストを許容していない」という声明に矮小化した。これらは容易に反論できる藁人形だ。

I could go on to highlight in detail other flaws in the ISO response — the failure to address the criticism that the standards weren’t based on research or experience that demonstrates the validity of that approach, the failure to answer the concern that the standards will lead to compulsion by the back door, the failure to address the charge from the founders of Context-Driven Testing that the standards are the antithesis of CDT, and the evasion of the documented links between certification and standards.

その他、ISOの反応には「妥当性を示す研究または経験に標準が基づいていない」という批判に対応できていないこと、標準を内輪で決めて押し付けて来るという懸念に対応できていないこと、コンテキスト駆動テストの提唱者からの「標準はコンテキスト駆動テストと正反対である」という批判に対応できていないこと、認証と標準の文書による紐付けについての責任逃れ、といった手落ちをハイライトすることができる。

In the case of research, Dr. Reid told us of the distinctly underwhelming claims from a Finnish PhD thesis that the standards represent “a feasible process model for a practical organization with some limitations.” These limitations are pretty serious — “too detailed” and “the standard model is top-heavy.” It’s interesting to note that the PhD study was produced before ISO 29119 part 3 was issued; the study does not mention part 3 in the references. The study can therefore offer no support for the heavyweight documentation approach that ISO 29119 embodies.

このうち研究についての反応では、Reid博士は「標準は『若干の制約を伴う、現実的な組織で有効なプロセスモデル』だ」という、明らかにがっかりさせられるフィンランドの博士の論文を提示している。
ここでいう「制約」は若干でなくかなり深刻である。あまりに詳細すぎ、頭でっかちな標準モデルである点でだ。
またその博士の研究が、ISO29119 Part3の発行前に作られており、Part 3への参照がないのに留意すべきだ。提示されている研究が、ISO29119の重量級のドキュメンテーションのアプローチの支持として、有効でないということだ。

So instead of standards based on credible research, we see a search for any research offering even lukewarm support for standards that have already been developed. That is not the way to advance knowledge and practice.

信頼できる研究に基づいて標準を作るのではなく、すでに開発された既存の標準を中途半端にサポートする研究を見つけてきているのが目につく。これは知識やプラクティスを進化させる方法ではない。

These are all huge concerns, and the software testing community has received no satisfactory answers. As I said, we should always confront our opponents’ strongest arguments in a debate. In this case, I’ve run through the only arguments that ISO have presented. Is it any wonder that the ‘Stop 29119′ campaigners don’t believe we have been given any credible answers at all?

強い懸念が存在するまま、結局ソフトウェアテストのコミュニティは満足できる返答をもらえなかった。
前述の通り、ディベートでは常に最も強い声明に対して正面から対応すべきだ。
今回のケースでは、ISOが提示した唯一の声明に目を通した。Stop 29119の推進者が信頼できる解答を得られたと考えていない現状は、奇妙ではないだろうか？

What will ISO do? Does it wish to avoid public discussion in the hope that the ISO brand and the magic word “standards” will help them embed the standards in the profession? That might have worked in the past. Now, in the era of social media and blogging, there is no hiding place. Anyone searching for information about ISO 29119 will have no difficulty finding persuasive argumentsagainst it. They will not find equally strong arguments in favor of the standards. That seems to be ISO’s chice. I wonder why.

これからISOは何をするだろうか？ISOブランドと”標準”という魔法のワードで、職場を標準で埋めていけるという願望の元に、パプリックな議論を避け続けることを希望しているのだろうか？
その対応はかつては有効だったかもしれない。しかし今は、ソーシャルメディアやブログの時代であり、隠れ場所はない。ISO29119 関連の情報を検索する者ならばだれであっても、説得力のあるISO29119への反対意見を容易に見つけるだろう。一方で、標準を強く支持する主張は同じようには見つけられないだろう。
これはISOの選んだ選択のようだ。

29119

（訳注：このページは、ISO/IEC JTC1/SC7/WG26のWebサイト（http://softwaretestingstandard.org/）に掲載されている"Response to Stop 29119 Petition“の日本語訳です。文書の性質上なるべく正確さを期すようにしていますが、念のため英文を掲載して対訳形式にしています。この文書はWG26に公式に認められています。翻訳はASTER（ソフトウェアテスト技術振興協会）として、にしが行いました。翻訳部分の全ての文責は翻訳者に帰着します。もし誤訳や不適切な部分があれば、Yasuharu.Nishi@uec.ac.jpまでお知らせ下さい。）

ISO 29119 Background / ISO 29119 の背景

Up until last year there was no comprehensive set of international software testing standards. There are standards that touch upon software testing, but many of these standards overlap and contain what appear to be contradictory requirements with conflicts in definitions, processes
and procedures. There are some useful IEEE testing standards (e.g. IEEE 829, IEEE 1028) and national standards (e.g. BS 7925-1/-2) but there were large gaps in the standards relating to
software testing, such as organizational-level testing, test management and non-functional testing, where no useful standards existed at all. This means that consumers of software testing services (and testers themselves) had no single source of information on good testing practice.

昨年まで、ソフトウェアテストに関する包括的な国際標準はありませんでした。ソフトウェアテストに触れている標準はいくつかありますが、多くは重複しており、また定義やプロセス、手順に一貫していないところがあり矛盾した要求を含んでいるようです。IEEE（米国電気電子学会）の標準（IEEE829、IEEE1028など）や国家標準（BS 7925-1/02など）といったテストに関する有用な標準もありますが、組織レベルのテスト、テストマネジメント、非機能テストなどに大きなギャップがあるため、本当に有用な標準とは言えませんでした。これはテストサービスを活用する顧客（そしてテスト技術者自身）にとって、よいテストに関する情報をまとめて提供してくれるものが無い、ということを意味しています。

Given these conflicts and gaps, developing an integrated set of international software testing standards that provide far wider coverage of the testing discipline provided a pragmatic solution to help organizations and testers. And ideally this initiative would not re-
invent the wheel, but build upon the best of the available standards;
thus the motivation for the ISO/IEC/IEEE 29119 set of standards.

こういった矛盾やギャップを考慮すると、テストのdisciplineをとても広くカバーするまとまった国際標準を作成することが、テストを行う組織や技術者の助けとなる実践的な解を提供することになるわけです。理想を言えばこの活動は車輪の再発明になるべきではないでしょうが、実際のところこれまでの標準の優れたところを踏まえて作成することになるでしょう。これが、ISO/IEC/IEEE 29119シリーズの国際標準を作成する動機です。

In May 2007 ISO formed a working group to develop new standards on software testing – a new area for ISO. The scope of this initial work (ISO/IEC/IEEE 29119 parts 1, 2, 3 & 4) was largely defined by the existing IEEE and BSI standards (which they would replace), although it was clear from the onset that a completely new 'Test Processes’ standard would be required, in particular to ensure that agile life cycles and exploratory testing were considered, as well as more traditional approaches to software projects and to testing. Subsequently, work on a 'Test Assessment’ standard (ISO/IEC 33063) based on the 'Test Processes’ standard started. Much later (in 2012) a standard on Keyword-Driven Testing (ISO/IEC/IEEE 29119-5) was begun, and a proposal for a standard on 'Work Product Reviews’ is currently under ballot.

2007年5月にISO（国際標準化機構）は、これまで手がけてこなかったソフトウェアテストの分野で新しい標準を作成するWG（ワーキンググループ）を設立しました。初期の成果物（ISO/IEC/IEEE 29119 part 1～4）の範囲は（後にISO 29119シリーズに置き換えられることになる）IEEEやBSI（英国規格協会）の標準で既に広く定義されているものでしたが、テストプロセスに関する全く新しい標準を手がけること、特に、伝統的なソフトウェア開発やテストだけでなく、アジャイル開発や探索的テストも考慮にいれることが必要なのは明白でした。続いて、テストプロセスに関する標準を基にして、テストアセスメントに関する標準（ISO/IEC 33063）の作成も開始されました。さらにその後（2012年）、キーワード駆動テスト（ISO/IEC/IEEE 29119-5）に関する標準の作成が開始されました。ワークプロダクトレビューに関する新規作成の提案も現在投票中です。

The current set of standards handled by WG26, the joint ISO/IEC/IEEE working group on software testing, is shown below:

  • Concepts and Definitions (ISO/IEC/IEEE 29119-1) – published August 2013
  • Test Processes (ISO/IEC/IEEE 29119-2) – published August 2013
  • Test Documentation (ISO/IEC/IEEE 29119-3) – published August 2013
  • Test Techniques (ISO/IEC/IEEE 29119-4) – due for publication in 2014
  • Keyword-Driven Testing (ISO/IEC/IEEE 29119-5) – due for publication in 2015
  • Test Assessment (ISO/IEC 33063) – due for publication in 2014/2015
  • Work Product Reviews (awaiting approval – working draft available)

以下に、現在WG26が取り扱っている標準を示します（訳注：2015年1月時点の情報で翻訳しています）：

  • コンセプトと定義（ISO/IEC/IEEE 29119-1） – 2013年8月発行
  • テストプロセス（ISO/IEC/IEEE 29119-2） – 2013年8月発行
  • テスト文書（ISO/IEC/IEEE 29119-3） – 2013年8月発行
  • テスト技法（ISO/IEC/IEEE 29119-4） – 2015年発行予定
  • キーワード駆動テスト（ISO/IEC/IEEE 29119-5） – 2015年発行予定
  • テストアセスメント（ISO/IEC 33063） – 2015年発行予定
  • ワークプロダクトレビュー（ISO/IEC 20246） – ワーキングドラフト準備中

The first three of these standards were published over a year ago, and were available as drafts for several years prior to that. Both the IEEE and BSI contributed existing standards, which were themselves developed by consensus over many years, as source documents to the project (these
standards will be retired as the new standards are published).

始めの3つの標準は1年以上前に正式に発行されており、ドラフトとしてはその数年前から入手可能になっています。IEEEとBSIはそれ以前に何年もかけてコンセンサスを確保しながら標準を作成していたのですが、それらがこのプロジェクトのソース文書となっています（IEEEとBSIの標準は、29119シリーズに統合されます）。

The availability of these international testing standards provides a
number of potential benefits:

  • Improved communication – through a common terminology.
  • Definition of good practice in the testing industry – a guideline for testing professionals, a benchmark for those buying testing services and a basis for future improvements to testing practices. Note that we do not claim that these standards define 'best practice’, which will change based on the specific context.
  • A baseline for the testing discipline – for instance, the standard on test techniques and measures provides an ideal baseline for comparison of the effectiveness of test design techniques (for instance, by academics performing research) and a means of ensuring consistency of test coverage measurement (which is useful for tool developers).
  • A starting point – for any organization that is looking to define their testing processes, templates, techniques or concepts for the first time.

29119シリーズが入手できることによって、以下のような効果が期待できます：

  • コミュニケーションの改善 – 用語の共通化を通して可能になります。
  • テスト業界における優れた取り組みの明確化 – テストのプロフェッショナルのためのガイドラインにも、テストサービスを依頼する顧客のためのベンチマークにも、優れた取り組みに向かう改善の基盤としても役立ちます。ただし私たちは、29119シリーズが「ベストプラクティス」だと主張するつもりはありません。何がベストなのか、は状況によって異なるからです。
  • テストのdisciplineに対するベースライン – 例えばテスト技法の標準は、テスト設計技法の効果の比較のベースラインを提供します。これは学術的な実証研究などで可能になります。またテストの測定の標準は、テストカバレッジの測定の一貫性を保証する手段を提供します。これはツールベンダにとって有用です。
  • きっかけ – 自分たちのプロセスやテンプレート、技法、コンセプトを最初に定義するために何かいいものを探している組織に有用でしょう。

Petition and Response /
29119シリーズに対する反対請願（Petition）とそれに対する回答

In August 2014 the following online petition was created and the
following is the response from the convenor of ISO Software Testing
Working Group (WG26), Dr Stuart Reid.

2014年8月に、以下のようなオンラインの反対請願が始められました。またそれらに対し、ISOのソフトウェアテストのワーキンググループWG26のコンビーナ（訳注：ワーキンググループのリーダのこと）であるStuart Reid博士が回答を以下のように行っています。

“To the President of the International Organization for Standardisation, We, the undersigned, hereby petition the International Organization for Standardisation to suspend publication of ISO/IEC/IEEE 29119-4 and ISO/ IEC/IEEE 29119-5, and to withdraw ISO/IEC/IEEE 29119-1, ISO/IEC/IEEE 29119-2 and ISO/IEC/IEEE 29119-3. It is our view that significant disagreement and sustained opposition
exists amongst professional testers as to the validity of these standards, and that there is no consensus (per definition 1.7 of ISO/IEC Guide 2:2004) as to their content."

「国際標準化機構（ISO: the International Organization for Standardisation）会長（President）宛： 我々この反対請願に署名する者は、ISO/IEC/IEEE29119-4, 5の発行の延期と、ISO/IEC/IEEE29119-1, 2, 3の廃止を請願します。我々は、これらの標準の妥当性についてプロフェッショナルのテスト技術者の間でかなりの反対（significant disagreement）と継続的な異議（sustained opposition）が存在し、内容についてコンセンサス（ISO/IEC Guide 2:2004のdefinition1.7に書かれています）が存在しないという見方をしています。」

Members of the ISO Software Testing Working Group (WG26) are well-versed in the definition of consensus. The six years spent in gaining consensus on the published testing standards provided us all with plenty of experience in the discussion, negotiation and resolution of technical disagreements – if nothing else, we are now experts at compromise and reaching consensus.

ISOのソフトウェアテストのワーキンググループ（WG26）のメンバは、コンセンサスの定義についてよく理解しています。29119シリーズに対するコンセンサスを得るために、6年の年月を経てきました。その間、技術的な反対に対して議論し、交渉し、解決するという多くの経験を積み重ねてきました。他のことはともかく、歩み寄りとコンセンサスに関して私たちは今のところ専門家になりました。

However, as a Working Group (WG) we can only gain consensus when those with substantial objections raise them via the ISO/IEC or IEEE processes. The petition talks of sustained opposition. A petition initiated a year after the publication of the first three standards (after over 6 years’ development) represents input to the standards after the fact and inputs can now only be included in futursussse maintenance versions of the standards as they evolve.

私たちにできることは、ISO/IECやIEEEのプロセスを通して提出された重要な異議に対して、ISOのワーキンググループ（WG）としてコンセンサスを得ることだけです。この反対請願は、継続的な異議について論じられています。最初の3つの標準は6年以上に及ぶ執筆編集の後に出版されましたが、ある反対請願はその1年後に始められました。現在のところ、反対請願は出版後になされたものであり、29119シリーズが将来進化する際の改訂にのみ含まれうる材料（input）になります。

It is unclear if 'significant disagreement’ reflects the number of professional testers who don’t like these standards or their level of dissatisfaction with their content, however the petition comments raise a number of issues which deserve a considered response:

「かなりの反対（significant disagreement）」が、29119シリーズを好まないプロフェッショナルのテスト技術者の数、もしくは内容に対する不満足さを反映しているかどうかは定かではありません。とはいえ、熟慮を要する回答を行うべき論点（issues）は増えてきています。

“The standards are not free." /
「標準なのに有償だ」

Most ISO/IEC/IEEE standards cost money (ISO is partially funded by the sale of standards), and the testing standards are no different in this respect. Personally, I would prefer all standards to be made freely-available, but I am not in a position to make this change – and do not know where the costs of development would come from. I can see that the charge made for the standards has forced a large proportion of those commenting on them to base their commentary on
second-hand descriptions of the standards – and with fuller access and better information I expect many of these people would have refrained from 'signing’ the petition and making incorrect statements about the standards.

多くのISO/IEC/IEEEの標準は有償です（ISOの活動の原資は標準の売上げによるものでもあります）。29119シリーズも例外ではありません。個人的には全ての標準は無償で入手できるべきだと思いますが、私はISOの仕組みを変える立場にありませんし、もしそうできたとしても標準を作成する原資をどこから得ればいいのかは分かりません。標準が有償であるため、標準にコメントしたい方々のかなりの割合が2次記述（訳注：標準そのものではなく標準について書かれた記事など）に対してしかコメントできないのは理解しています。もし標準が自由に入手でき、より良い情報に触れることができれば、反対請願に“署名した”方々の多くが署名しなかったでしょうし、標準に対する誤った意見表明もしなかったでしょう。

“The standards 'movement’ is politicized and driven by big business to the exclusion of others." /
「標準化“活動”は、巨額の利益を生むビジネスを自分たちで囲い込むための政治的な運動だ」

A large proportion of the members of WG26 are listed at our About WG26 page along with their employers. This list does not support the assertion in the petition. The seven editors (who do the
majority of the work) are from a government department, a charity, two small testing consultancies, a mid-size testing consultancy, a university and one is semi-retired. All WG members give their time
freely and many use their own money to attend meetings. As all received comments have their resolution fully documented anyone who submits a comment on a draft standard can easily see how their suggested change was handled – thus even those who cannot afford the time to come to WG meetings can easily influence the content of the standards. IEEE balloting also extends the consensus. For example, the IEEE balloting group for ISO/IEC/IEEE 29119-4 contains 76 people: 5 identify themselves as academic; 11 consultants; 9 government and/or military; 5 process management; 7 software producers; 5 project managers; 12 software product users/acquirers, and 21 with general interest.

WG26のWebページには、WG26のメンバのリストが所属と共に掲載されています。このリストを見れば、この反対請願の主張が支持されないことが分かります。7人のエディタ（かなりの執筆作業を行ってくれました）の所属は、政府機関、ボランティア、2つの小さなテストコンサルティング企業、中規模のテストコンサルティング企業、大学、そしてセミリタイア（訳注：長年勤めていた大きな企業を早期退職し独立して個人でコンサルタントを務めている）です。WGのメンバは全員自分の時間をたくさん費やし、その多くは自費で標準化の会議に参加しています。会議に提出された全てのコメントは、きちんと解決（resolution、訳注：コメントに従って標準案が修正されたり、コメントに従わないことを提出国が納得し同意すること）され文書化されますので、標準案に対してコメントを提出した人は誰でも簡単にコメントの結果を確認することができます。すなわち、WG会議に来る時間が無い人でも、自分が標準の内容にどのように影響を与えたかを簡単に確認することができるわけです。IEEEはそうしたコンセンサスを基に、さらに投票を行ってもいます。例えば、29119-4に対する投票グループは76名います。内訳は、5人は学術機関、11人はコンサルタント、9人は政府機関や防衛関連、5人はプロセスマネジメント、7人はソフトウェア開発者、5人はプロジェクトマネジャー、12人はソフトウェア製品を利用・購入する顧客、その他が21人です。

“The methods advocated haven’t been tried and the standards do not emerge from practice." /
「この標準で提案されている方法は十分に適用されているわけではなく、またこの標準は現場の実践から生み出されたものではない」

The number of years’ and range of testing experience on the Working Group (and the number of countries represented) shows that a wide range of experiences have been drawn on to create the standards. Early drafts were widely distributed and many organizations started (and continue) to use the standards – and so provided important feedback on their use to allow improvements to be made. At least one academic study at PhD level has been performed on the use of these early drafts within 14 different software organizations by Jussi Kasurinen of Lappeenranta University of Technology. Three of the main contributions of the thesis were described as: The concepts presented in the ISO/IEC 29119 test process model enable better end-product quality. The ISO/IEC 29119 test standard is a feasible process model for a practical organization with some limitations. The ISO/IEC 29119 test standard is a feasible foundation for a test process development framework.

WGに集まった何ヶ国もの代表の経験を基に何年もかけて議論したことは、29119シリーズをつくるために幅広い経験が引き出されたことを示しています。初期の標準案は広く配布され、多くの組織が適用し始めました（そして使い続けています）。そして重要なフィードバックが得られ、改善につながりました。ラッペーンランタ大学（Lappeenranta University of Technology）のJussi Kasurinenは、14の異なるソフトウェア組織に対して初期の標準案を適用するという博士号レベルの研究を行っています。この論文の3つの主要な結論は、以下の通りです：29119シリーズのテストプロセスモデルで提示されているコンセプトは、最終製品の品質をより高くできます。いくつかの制約はありますが、実際の組織で実現可能なプロセスモデルです。テストプロセスを構築するフレームワークの実現可能な基礎になります。

“The standards represent an old-fashioned view and do not address testing on agile projects." /
「この標準はアジャイルプロジェクトに対して論じておらず、時代遅れの代表である」

The standards were being continually updated until 2013 and so are inclusive of most development life cycles, including agile. As an example, the test documentation standard (ISO/IEC/IEEE 29119-3) is largely made up of example test documentation and for each defined document type example documentation for both traditional and agile projects is provided. The standards will be regularly reviewed and changes based on feedback from use have already been documented for the next versions.

29119シリーズは2013年から継続的に改訂されており、アジャイルを含むほとんどの開発ライフサイクルを含んでいます。例えば、29119-3（テスト文書）の大半はテスト文書の事例から構成されており、各文書に対して非アジャイルととアジャイルの両方の例を掲載しています。29119シリーズは、現在の版を利用した方々からのフィードバックを基に、次版に向けて定期的にレビューされ改訂されています。

“The standards require users to create too much documentation." /
「この標準は利用者に膨大な文書化を求める」

Unlike the IEEE 829 standard, which it replaces, the test documentation standard, ISO/IEC/IEEE 29119-3, does not require documentation to follow specific naming conventions nor does it require a specific set of documents – so users can decide how many documents to create and what to call them. The standard is information-based and simply requires the necessary test information to be recorded somewhere (e.g. on a Wiki). As stated above, it is fully aligned with agile development approaches and so users taking a lean approach to documentation can be fully compliant with the standard.

テスト文書に関する（29119シリーズに統合された）IEEE829標準とは異なり、29119-3は特定の文書名も文書のセットも要求しません。利用者がどの文書をどう呼んでどう利用するかを決められるのです。29119-3は、文書に記載される必要のある内容について求めています。別にWikiに書いても構いません。上で述べたように、アジャイル開発アプローチにも沿っていますので、リーンな文書化のアプローチを採用している方々にも29119-3は十分適合します。

“The existence of these standards forces testers to start using them." /
「標準が存在すると、テスト技術者がそれに従うことを強制される」

According to ISO, standards are “Guideline documentation that reflects agreements on products, practices, or operations by nationally or internationally recognized industrial, professional, trade associations or governmental bodies".

ISOによると、標準は「国内もしくは国際的に認められた企業団体や技術者団体、業界団体、政府機関による合意を反映した製品、方法、操作のガイドライン文書」です。

They are guideline documents therefore they are not compulsory unless mandated by an individual or an organization – it is up to the organization (or individual) as to whether or not following the
standards is required, either in part or in their entirety. However, if specified in a contract then they can define requirements on the testing, but as with all contracts this depends on the signatories. Because the standards includes the ability to apply its requirements in a range of
lifecycles, including agile, if a company is required to use the standards it will not prevent an agile approach.

標準はガイドライン文書ですから、特定の個人や組織によって義務として求められない限り、強制ではありません。標準の一部を義務として求めるのか、それとも全部なのか、も同様です。契約に記載されればテストに対する要求事項を明示しなくてはなりませんが、その契約にサインするかどうかは当事者の問題です。例えば、29119シリーズはアジャイルを含む開発ライフサイクルにおいて契約の要求事項を実現する能力を提供しますので、もしある企業が標準を使うことを要求しても、アジャイルアプローチを採ることを妨げません。

My view of the testing standards is that they will be of most use to testers who want to see a definition of good practice and see how close (or far) they are away from it. They can then decide if they wish to change their practices and if they wish to adopt the standard then they
are free to tailor it to suit their needs. One of the most common uses I make of the testing standards is to use them as checklists – I then have more confidence that I haven’t accidentally ignored an important aspect of the testing.

私見ですが、テストの標準は、よい取り組みの定義と、自分たちがどれくらいそれに近い（遠い）のかを知りたいテスト技術者にとても有用です。自分たちの取り組みを改善したいと望めば始められますし、標準を採用したいと望んだとしても自由に自分たちのやり方に合わせることができます。私が行っているこの標準の一般的な使い方は、チェックリストです。何か重要な側面をたまたま見逃していないかどうかの確信が持ちやすいですから。

“The Testing Standards are simply another way of making money through certification." /
「この標準は単に認証を通してカネを生むための新たな手段である」

There is currently no certification scheme associated with the testing standards, and I am not aware of one being developed. There is also no link between the ISO/IEC/IEEE Testing Standards and the ISTQB tester certification scheme. The ISTQB scheme could align with the body of knowledge represented by the ISO/IEC/IEEE testing standards, but that is a decision for those who run ISTQB.

現在のところ29119シリーズに関する認証制度はありませんし、そうした動きを私は知りません。同様に、ISTQBの技術者認定制度との関係もありません。ISTQBの制度が29119シリーズに示された知識体系に従う可能性はありますが、それはISTQBを運営している人たちが決めることです。

“The Testing Standards do not allow exploratory testing to be used." /
「この標準は探索的テストを許容していない」

Exploratory testing is explicitly included as a valid approach to testing in the standards. The following is a quote from part 1:"When deciding whether to use scripted testing, unscripted testing or a hybrid of both, the primary consideration is the risk profile of the test item. For example, a hybrid practice might use scripted testing to test high risk test items and unscripted testing to test low risk test items on the same project."

探索的テストは、価値の高いアプローチだと29119シリーズで明記されています。以下の引用は29119-1からのものです： “記述的なテストを行うか非記述的なテストを行うか、もしくは両者を混合して行うかを決める際には、テスト対象のリスクプロファイルを考えるのが第一です。例えば同じプロジェクトで両者を混合して行う場合、リスクの高いテストは記述的なテストを行い、リスクの低いテストは非記述的なテストを行う、といった方法がありえるかもしれません。”

If using exploratory testing (and also wanting to show compliance with the standard) then a simple rationale for not documenting tests in advance would be required. The standard also does not require the tests executed during an exploratory testing session to be documented – it does require they be “recorded", but this could be with a screen reader or as notes in a session sheet, and even this requirement can be tailored out if an organization deemed such recording as unnecessary.

（29119シリーズに適合する形で）探索的テストを行う場合、事前に文書を作成しないテストでよいという点について、簡単な理由が必要になります。同様に29119シリーズは、探索的テストのセッションで実行されたテストを文書化せよという要求もしていません。“記録”の形で十分ですし、何ならスクリーンリーダーを使っても、セッションシートへのメモでも構いません。その組織が不必要だとみなすのであれば、記録は不要だというようにテーラリングすることもできます。

“No-one knew about the standards and the Working Group worked in isolation." /
「この標準やワーキンググループが密室で決められていることを誰も知らない」

From the outset the development of the testing standards has been well-publicised worldwide by members of the Working Group at conferences, in magazine articles and on the web. Early in the
development, in 2008, workshops were run at both the IEEE International Conference in Software Testing and the EuroSTAR conference where the content and structure of the set of standards were discussed and improved. The working group also went to great lengths to invite the broader testing community to comment on the standard and to voice their opinions at meetings of our software testing standards working group, by placing information on the softwaretestingstandard.org website on how individuals can get involved in the development of the standard (see our How to Get Involved page). Since then I have lost count of the number of testing conferences where the standards were presented on and discussed. At every one of my presentations on the standards I have invited the audience to become involved in their development. Of course, I am not the only person who has spoken about the standards – experts from many countries have spoken about the standards and invited participation.

29119シリーズの作成は、WGのメンバによって講演されたり雑誌やWebの記事として執筆されて、始めから広く公表されています。作成初期の2008年には、ICSTというIEEEのテストの国際学会やEuroSTARというカンファレンスの両方でワークショップが開催され、29119シリーズの内容や構造が議論され改善されました。WGとしても、私たちのWGの会議の場で29119シリーズにコメントや意見を頂くべく、幅広いテストのコミュニティをお呼びするために色々尽力しました。個人として29119シリーズの作成に参加するための情報も、私たちのWebサイト（softwaretestingstandard.org）に載せています。2008年以後は、覚えきれないほどの数のカンファレンスに出席し、29119シリーズについて紹介し議論してきています。私はその都度、29119シリーズの作成に参加してもらうよう聴衆に呼びかけてきました。もちろん、私だけが29119シリーズについて話すわけではりません。多くの国のエキスパートが29119シリーズについて講演の依頼を受けています。

Testing experts from around the world were invited to take part in the development of the standards – these included a number of prominent members of the AST who were personally approached and asked to contribute to the standards early in their development, but they declined to take part. Other members of the AST have provided input, such as Jon Hagar, who is the IEEE-appointed Project Editor – and he has presented on the standards at the CAST conference.

29119シリーズの作成には、世界中からテストのエキスパートが参加しています。その中には、作成初期に個人的にアプローチし貢献したいと問い合わせてこられたAST（訳注：Association for Software Testing。この反対請願の原動力となっている団体）の著名なメンバもいます。その後辞退されましたが。また、29119シリーズに貢献しているASTのメンバもいます。IEEEから参加しているプロジェクトエディタのJon Hager氏です。CASTカンファレンス（訳注：ASTの年次カンファレンス）で29119シリーズについて発表も行っています。

“No-one outside the Working Group is allowed to participate." /
「WG以外からの参加は許されない」

There are a number of options for those interested in contributing to the standards – and these are all still open. The Working Group (WG) meets twice a year for 6 days – and is made up of experts acting in a personal capacity, appointed by national standards bodies, such as ANSI, or liaising organizations (e.g. IEEE). Most experts at Working Group meetings are supported by a 'mirror panel’ in their home country who act as reviewers and submit comments on the drafts. Many of these mirror panel members represent specific industry areas (e.g. financial testing), testing roles (e.g. independent consultant) or testing interest groups. These comments are then collated and moderated by the mirror panel to remove duplicates and contradictory suggestions before being submitted to the WG. The Working Group also accepts comments directly from any individual with an interest in software testing. Each comment is individually handled and the response to the comment is agreed by the WG and is fully documented. As an example, the WG itself resolved well over 3000 comments on the 'Test Processes’ standard. All comment resolution files are then circulated back to each country’s mirror panels, so that individual contributors can see how their comments were handled by the WG. This makes it a very transparent process that is accessible to any tester, anywhere.

29119シリーズに貢献する選択肢はいくつかあり、どれも有効です。WGは年に2回の会議を開催しています。会議は参加するエキスパートの個人的な尽力によって支えられており、またANSI（訳注：米国国家規格協会）のような国内標準化団体やIEEEのようなリエゾン組織とで日程調整がなされています。WG会議に出席するエキスパートのほとんどは、標準案をレビューしコメントを作成する自国の「ミラー組織」の窓口として出席しています。ミラー組織のメンバーは、金融分野のテストといった産業分野や独立コンサルタントといった職種、テスト関連の団体を代表しています。作成されたコメントは、重複したコメントや矛盾したコメントが無いよう、WGに提出される前に照合されてミラー組織によって整理されます。WGは、ソフトウェアテストに関心のある人なら誰からでも直接コメントを受け付けます。それぞれのコメントは、コメントごとに検討され、WGでの合意のもとに対応案が作成され、きちんと文書化されます。例えば、29119-2（テストプロセス）では3000をはるかに超えるコメントがWGで対応（resolve）されました。コメントに対する全ての対応が入ったファイルは各国のミラー組織に送付されますので、個人として貢献した方々は自分のコメントがどう対応されたかを見ることができます。これは、どこに住んでいるどんなテスト技術者にとっても、非常に透明なプロセスです。

“Context-Driven Testing isn’t covered by the standards." /
「29119シリーズでは、コンテキスト駆動テスト（Context-Driven Testing）はカバーされていない」

I fully agree with the seven basic principles of the 'Context-Driven School’ at http://context-driven-testing.com. To me most of them are truisms, and I can see that to those new to software testing they are a useful starting point. I also have no problem with context-driven testers declaring themselves as a 'school’, however I am unhappy when they assign other testers to other deprecated 'schools’ of their own making.

私は、http://context-driven-testing.comに載っている「コンテキスト駆動学派（Context-Driven School）」の7つの基本原則は全く正しいと思います。私にとってほとんどは自明のことですが、ソフトウェアテストを始めたばかりの技術者には有用なきっかけになるという点も理解しています。コンテキスト駆動の立場を取る技術者が自分たちを「学派（school）」と宣言するのは別に構いませんが、そうでない技術者を「反対派」のように扱うのは残念ですね。

Jon Hagar, the Project Editor for the ISO/IEC/IEEE 29119 set of standards, is a supporter of the context-driven school and he, along with the rest of the Working Group, ensured that that many of the context-driven perspectives were considered. For instance, the following statement is early in part 1: “Software testing is performed as a context-managed process."

29119シリーズのプロジェクトエディタであるJon Hagerはコンテキスト駆動学派の支持者ですが、WGの他のメンバと同様に、29119シリーズにはコンテキスト駆動の考え方が考慮されていると考えています。例えば、29119-1の最初の方には「ソフトウェアテストは、コンテキストをきちんと考えたプロセス（context-managed process）で行われるものである」と書いてあります。

The standards do, however, also mandate that a risk-based approach is used, as can be seen in the following quote (also from part 1): “A key premise of this standard is the idea of performing the optimal testing within the given constraints and context using a risk-based approach." I see no problem in following both risk-based and context-driven approaches simultaneously as I believe the context and the risk-profile to be part of the same big picture which I would use to determine my
approach to the testing.

とはいえ29119シリーズでは、リスクベースのアプローチを用いることを求めています。29119-1には「リスクベースのアプローチを用いて与えられた制約やコンテキストを満たしながら最適なテストを行うという考え方は、29119シリーズの重要な前提である」と書いてあることが分かります。私自身は、リスクベースのアプローチとコンテキスト駆動のアプローチを同時に追求することは問題無いと思いますし、コンテキストとリスクプロファイルは両方とも、私がテストのアプローチを決める時に考慮する全体像の一部だと信じています。

Dr Stuart Reid
Convenor, WG26
8th September 2014

2014年9月8日

WG26コンビーナ Stuart Reid博士