Frequently-Asked Questions About the 29119 Controversy /
29119に関する議論のFAQ）

（訳注：このページは、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を訪れてほしい。感謝する。