「観点の蒸留」

~腕利きソフトウェアテストコンサルタントが支える優理の事件簿・アドベントカレンダー2016/12/15番外編~

著者: にし やすはる

「あ~、忙しい忙しい。やることは山ほどあるのに、時間は全然足りないよ。でも早く一人前のQAマンにならなくちゃ。頑張るぞ!」

鳥刈は誰かに聞いて欲しいわけでもなく、しかし独り言にしてはずいぶん大きな声で呟きながら会議室のセッティングをしていた。今日はいつも先輩が受けているコンサルティングを自分一人で受けられる、またとないチャンスだ。勉強ならたくさんしている。本もいくつも読んだ。いろんな勉強会に出席した。SNSでも凄い人たちと友達のように会話できる。その成果をコンサルの人に誉めてもらおう。奥村先輩はいっつも「お前は熱心なんだけどさ、ちょっと空回りなんだよなぁ...。」と苦笑するけど、あんな呑んでばっかりの人じゃ分かってくれない。優秀なコンサルなら分かってくれるはずだ。こないだだって、開発の安達部長から「期待してるよ」って声をかけてもらったんだぞ...と言わんばかりに、全く汚れていないテーブルを、頼まれてもいないのに力を込めて一生懸命拭いている。20代の若さの分だけ机がキュッキュと音を立てた。

「こんにちは。いつもお世話に...あれ?奥村さんはどうされました?」

ここのところずいぶん寒くなったのにジャケットだけで登場する姿はスマートだ。母さんの手編みの毛糸のマフラーをしている僕とは違う。一瞬同性に見惚れてしまった鳥刈は、すぐに我に返って軽く声を上ずらせながら答えた。

「すみません、急病で奥村先輩はお休みなんです。あいにくQA部長も出張で留守にしてまして、もしよろしければ私だけでお話を伺ってもよろしいでしょうか。」

水元は、首から上だけのお辞儀で恐縮した風を見せながら気負っている雰囲気が漏れ出てくる若さに微笑みつつ、「構いませんよ。でも前回の宿題は...?」と尋ねながら席に着いた。コンサルタントという職業柄、クライアントがバグ対応で欠席するなど珍しくもなんともない。会社の前まで来て中止のメールが来たこともある。熱心な若者の力になれるのであれば嬉しい限りだ。

「すみません。そちらも次に回して頂けますでしょうか。今日はちょっと『テスト観点』についてお伺いしたいんです。」

なんかさ、よろしくやっといてよ、と先輩は電話で言った。うん、言った。僕はそう聞いた。だったら、せっかくの機会なんだから自分の実力アップに使おう。こないだ呑み会で先輩は「お前の信じる道を行け」とも行ってくれたじゃないか。なんだか覚えてなさそうだけど。

「ふむ...いいですよ。どんな質問ですか?」

「インターネットで各社の動向を調査したんです。『テストの切り口』とか『どうテストするか』とか抽象的には分かります。でも具体的なものが欲しいと思ってテスト観点の表みたいなものをダウンロードすると、なんか違和感があって...。ずっとモヤモヤしてるんです。教えてください。テスト観点って、なんですか?」

どうして不明点を説明し終わってドヤ顔をしているんだろう、という疑問が頭をかすめたが、水元の頭脳の焦点はそれどころではなかった。この質問に答えはないからだ。

なぜ答えがないのか。質問者は字面としてテスト観点の定義を質問してくる。しかし実のところ彼らが聞きたいのは「良い」テスト観点の挙げ方であり、それが「良い」ことの保証である。質問にまともに答えるとずいぶん哲学的な定義の話になるし、モヤモヤは消えず不承不承納得した表情をして話は終わりになる。誰も得をしない。

だからといって「良い」テスト観点について答えるのも難しい。結果として得られたテスト観点の良し悪しよりも、そこに至る過程でどこまでケンケンガクガクあーでもないこーでもないと議論して、時には白熱して、そして皆が納得感を共感することが大事だからである。誰かから「良い」テスト観点をもらってきたとしても、すぐに陳腐化する。水元はそのことをよく知っているし、少なくないエネルギーを費やしたコンサルティングの成果がクライアント側で水の泡になってしまって臍を噛んだこともある。どうしたものか...。

「百聞は一見にしかず、とか、論より証拠、と言いますよね。せっかく今日は鳥刈さんのお話をゆっくり伺えるので、ちょっと手を動かしながら実例を見てみましょうか。」

実例!そう、僕に足りないのは経験だ。勉強はたっぷりした。勉強会に出て凄い人たちの経験談も聞いた。でも先輩は微妙な顔をする。きっと僕に足りないのは経験だ。経験さえ積めば先輩も分かってくれる。それには実例が一番だ。さすが腕こきのコンサルタント。高いだけあって、クライアントのニーズに的確に答えてくれる。

「そうですね!よろしくお願いします!」

             ☆                  ☆

「あまり大きな実例ではかえって話が分からなくなりますから、すごく小さな例にしましょう。でもご心配なく。とても大事なエッセンスが詰まっていますから。」

えー。小さな例なら、勉強会でも聞けるじゃないか。鳥刈は少しがっかりした。

「鳥刈さんがダウンロードしたテスト観点の表は、どんな表でしたか?」

「なんだか機能仕様書から抜き書きして非機能要求をおまけに付けた感じだったり、あれしろこれしろここ見ろあそこ見ろのリストだったりして、なんだか歴史の年号の暗記みたいでした。あれを見て上手にテストできる感じはしませんでした。」

「なるほど。じゃあ実際に、手を動かしてみましょう。ここからダウンロードして...そうです。で、こうするとテキストファイルが開けますね。これは、+Lhacaという解凍ソフトのReadmeファイルです。読んだら、解凍のあたりのテスト観点図を作ってみて下さい。部分的で構いません。そんなに難しくないですね。」

水元はにこやかに促した。Xmindを立ち上げてすぐに、鳥刈は図を完成させた。

「おっ、早いですね。勉強熱心という噂は聞いていますよ。さすがです。」

誉められた!やはり見る目がある人は違う。先輩と大違いだ。鳥刈は鼻息が荒くなったことに気づかず、しかし意識の高い社会人に必要な謙譲の振る舞いとして顔の前で右手を振った。




【テスト観点図1】

「ふむ、なるほど。このテスト観点図の『意図』はなんでしょう?」

水元はまっすぐ鳥刈の目を見て言った。鳥刈はそのまま真っ向から見返して答えた。

「解凍機能の仕様確認です!」

「なるほど。まず、この段階ではそれで構いません。でも実際にテストをする時には、もう少し何か工夫をしませんか?」

「あー、そうですね。『1M以上』と書いてありますが、『とても大きい』にしてみると思います。」

「じゃあテスト観点図をリファインしてみましょう。」




【テスト観点図2】

「『1M以上』を『とても大きい』にしたのはなぜですか?」

鳥刈の目が少し泳いだ。

「何となく、何かが起きるかもしれないと思ったからです。」

「直感ですよね。直感、いいんです。大事にしましょう。さて改めて、とても大きくすると何が起きるでしょうね?」

「うーん、なんかあふれたり、とか?」

「なるほど。そうすると鳥刈さんのテストの“意図”は、『とても大きいサイズのファイルを解凍すると、なんかあふれるかも』なんですね。」

水元は注意深く、鳥刈の言葉を丁寧に紡いで投げ返した。誘導してしまうと、後で気づいて余計にモヤモヤするからだ。

「はい。そうなりますね。そうです。段々そうだって思ってきました。なんか元々そう思ってた気がします。」

鳥刈は暗示にかかりやすい。水元は、誘導してしまったかと心の中で軽く苦笑した。

             ☆                  ☆

「ところで、『あふれる』ってなんでしょう?」

水元は尋ねた。

「えーと、ディスクが一杯になって動かなくなる、とか。」

「その方が、テストの“意図”がはっきりしますね。言い直すと、『とても大きいサイズのファイルを解凍して、ディスクを一杯にして動かなくする』がこのテストの意図ですかね。このテストの意図は、2つの部分に分けられるんですが...

1) とても大きいサイズのファイルを解凍する

2) ディスクを一杯にして動かなくする

...本当に鳥刈さんがテストしたいのは、どちらでしょう?」

「2)です。」

「その場合、サイズが大きくなって欲しいのは、解凍前のファイルですか?」

「あー、違いますね。解凍後です。」

「じゃあテスト観点図をまたリファインしてみましょう。ただし分かりやすくするために、プログレスバーの確認は別で考えることにしましょう。」




【テスト観点図3】

「さっきより意図がはっきりした、すなわち“意図の解像度が上がった”気がすると思いますが、いかがですか?」

「うーん、確かにそうなんですが、まだモヤモヤしますね。」

鳥刈は首をひねりながら答えた。腕を組んで右手はアゴの下に当てている。首を左右交互に倒しているので、ばね細工のようだ。

「なぜでしょう?」

「解凍前のファイルと解凍後のファイルと両方あるからかな」

「解凍前のファイルは大きくなくてよいのですか?」

「いえ、解凍前が大きければ、解凍後も大きいですから。」

「圧縮形式は関係ない?」

「あー、もしかしたら関係するかも。いや、形式じゃないな。圧縮率とかだな。」

鳥刈の声が心持ち大きくなったことに二人は気づいていない。

「圧縮率?」

「はい、解凍前のファイルが大きくて、圧縮率が高ければ、解凍後のファイルも大きくなります。」

「なるほど。じゃあテスト観点図をリファインしてみましょう。




【テスト観点図4】

「ずいぶん“意図”がはっきりした気がしますね。」

「そうですね。そんな気がします。」

水元はこの答えの源泉が実感なのか暗示なのか不安だったが、これは実感してくれていると自分に暗示をかけて先に進むしかなかった。

             ☆                  ☆

「でもこのテスト観点図だと、相変わらずテストの意図は『解凍機能の仕様確認』になってますが、構いませんか?」

「いえ違います。『ディスクを一杯にして動かなくする』が意図ですから。」

「じゃあリファインしてみましょう。」




【テスト観点図5】

「こう、ですかね...?」

鳥刈は正解に向けて進んでいるのか不安になりつつある自分と、ほんの少しだが分かってきたという気持ちを臍のあたりで感じている自分との同居に戸惑っていた。水元はその戸惑いの理由を見透かして、鳥刈の背中を押すことにした。

「さっきのテスト観点図と今のテスト観点図を見比べて、気がついたことはありませんか?」

「あー、そうですね。別に解凍機能以外でもディスクを一杯にするテストってできるのかもしれません。圧縮とか。」

「じゃあまたリファインしましょう。ちょっとずつたくさんリファインしていいんですよ。中間作業成果物だと思うとやれ版管理だとかが気になりますが、いまのテスト観点図は鳥刈さんの理解を助ける相棒なんです。相棒と一緒に理解を深めているというイメージを持ってくださいね。」

「相棒...。相棒か...。」

鳥刈はまじまじとテスト観点図を見つめた。相棒と言われると、なんだか急に親しみが湧いてきた。嬉しくなってきた。また鼻息が荒くなってきた。




【テスト観点図6】

「どうですか?」

鳥刈は我に返った。

「いや...なんかムダっぽいです。同じようなテスト観点が並んでます...。」

相棒だったのに。一生懸命やったのに。ムダだった。もうダメだ。全然分からない。QAなんて向いてない。やっぱり開発の技術がなければテストなんてできないんだ。僕の人生はムダだった。鳥刈はポジティブな暗示にもかかりやすい分、ネガティブな暗示にもかかりやすい。肩を落としていると、水元はそんな鳥刈の顔を覗き込んでいたずらそうな顔でこう提案した。

「開発と同じですよ。似たようなソースコードがあれば共通化してサブルーチンとかライブラリにしますよね。テスト観点図で同じような構造が見えたら、テスト観点を一段階抽象化して、共通化しましょう。抽象化だと難しく聞こえるかもしれませんが、同じ役割をするものをグループにまとめて名前を付けるだけです。例えば、解凍と圧縮をまとめて『処理』と呼んでみましょうか。」




【テスト観点図7】

「どうですか?」

「すっきりしてきました...でももう少しすっきりできるかもしれません。」




【テスト観点図8】

鳥刈は目をぱちくりさせて、自分がいまリファインしたばかりのテスト観点図を眺めた。ずいぶん変わったな。

「なるほど。確かに、この方が意図が明確ですね。」

「ずいぶん分かりやすくなりました。変われば変わるもんですね。」

「でも、相変わらずテストの意図は『仕様確認』になってませんか?」

「あー、すぐ直します。」




【テスト観点図9】

「分かりやすいね。まぁ関連線をわざと描いてないのもあるけど。」

「分かりやすいですね...。意図がはっきり見えます。」

「ここまで分かりやすくなると、何か増やしたくなってこない?」

勝負所。誘導してはいけない。ここで誘導すると、すべてが水の泡。軽い口調で、あえて目を合わせず。言葉でも身振りでも指先でも目線でも、呼吸ですらもヒントを与えないように。水元は全身の筋肉がこわばり、汗が噴き出すのを感じていた。

「そうですねぇ...うーん...あー、ファイルのサイズが大きくなくても数が多ければいい、とか?」

水元の苦労など全く感じ取らず、鳥刈は答えた。水元は安心した。鳥刈はどうやら、ダイブと水元が呼ぶ状態に入っているようだ。考えている対象に集中でき、匂いや手触りを感じられるほどありありとイメージできる状態。潜っているのだ。クライアントがダイブしてくれたら、そのコンサルティングは成功である。放っておいても理解は進むし成果は出る。

「おー、新しい観点が出てきましたね。素晴らしい!じゃあリファインしましょう。」




【テスト観点図10】

「他に考えておくべき観点はありますか?」

「そうすると、ディスクの容量を減らしておいてもいいですね。」

「また新しい観点ですね!いいですよ、鳥刈さん、実にいい。さらにリファインしましょう。」




【テスト観点図11】

「なんか、いい感じですね。」

「なんか、いい感じですね。」

二人で目を合わせて、にんまりした。水元もまた、ダイブしているのだ。

「じゃあさらに一歩踏み込みましょう。一杯にできるのって、ディスクだけですかね?」

「メモリ!メモリも一杯にできます。そうすると、こうですかね。」




【テスト観点図12】

「そして抽象化。『記憶域』ですね。」

鳥刈はまるで10年以上もテスト観点図を作っているような調子で進めている。水元はその様子をウキウキしながら見ている。




【テスト観点図13】

水元はニヤリとしながら口を開いた。

「なにか違和感ない?」

テスト観点図に目線を一周させて、すぐに鳥刈は答えた。

「あります。『ファイル』だけやけに具体的。あと『圧縮率』も。」

「具体的って思うなら、抽象化してみましょう。」

「そうですね。ファイルは『リソース』かな。メモリだったらデータや文字列とかですかね。」

「圧縮率は『処理パラメータ』あたりにしておきましょうか。」




【テスト観点図14】

「どうですか?」

「なんだか、他のソフトのテストでも役立ちそうな感じです。圧縮ソフト以外でも。」

鳥刈は改めて驚いたようだった。

「最初のテスト観点図は役立ちそう?」

「いえ、あれは圧縮ソフト専用です。他のソフトには使えません。」

水元は立ち上がり、人差し指でリズムを取りながら解説を始めた。

「今日は鳥刈さんに『テスト観点の蒸留』という技を体験して頂きました。テスト観点図を描くときに網羅とかMECEばかりに気を取られると、仕様書やユーザマニュアルのコピペが主になってしまいますし、何より描きっぱなしになってしまいます。」

水元は頷いて肯定するように鳥刈を見つめて、言った。

「最初はそれでもいいんです、最初は。でもその後に、自分たちの意図を再検討したり、解像度を上げたりしながら、テスト観点図を何度もリファインしなくてはなりません。そうすると、テストの“知恵”が“蒸留”されてテスト観点図の上の方に浮かんできます。テストの知恵が蒸留されると、フロントローディングをして蒸留で品質を確保しやすくなります。逆に言うと、最初から完全なテスト観点図を描こうとしない方がいいですし、社外からテスト観点を買ってくるのも弊害が大きいんです。蒸留の過程で自分たちが分かっていくことそのものが大事ですから。」

             ☆                  ☆

「なるほど、テストの知恵かー。」

鳥刈は感心したように何度も頷いた。

「最後にできたテスト観点図が完全な模範解答なわけではありません。引き続き鳥刈さんが考えてリファインしていく必要があります。でも“蒸留”する感じは掴めましたかね。では、ポイントをまとめましょう。

1) 最初は仕様書やユーザマニュアルのコピペのテスト観点図でも構わない。まず描くことが大事。

2) 描いてみたら、ほんの少しでいいし経験や直感で構わないから、テスト観点図に工夫を加えてみる

3) 「意図のリバース」を行う。テスト観点図に加えられた工夫や、自然に描いたところから、一体自分はどういう意図でこのテスト観点を描いてるんだろう、と再検討してみる

4) 「意図の解像度の向上」を行う。テスト観点図に描かれた意図がはっきりするように、テスト観点図をリファインしたり、より深く検討してみる

5) 「知恵の蒸留」を行う。意図のリバースと解像度の向上をしながらテスト観点図をリファインすると、意図が徐々にトップに近い観点に浮かび上がってくる。

7) 「テスト観点の拡充」を行う。蒸留された知恵がテストのモデルのようなものになっているので、足りない構成要素を追加したり、そのモデルに該当する他のものに応用してみる。」

「テスト観点を育てる、って感じですね。子育てはしたことないけど、こういう風に無理せず見守りながら育てられたらいいなー。」

まだ実感がこもっていない。無理もない、鳥刈はまだ20代の若手だからだ。

「複数のテストエンジニアでテスト観点図を描いてるのであれば、『みんなでテスト観点図を育む(はぐくむ)』のかもしれません。愛を育むように、たくさん意図を話してお互いで理解しあって共通認識をどんどん改めていって、テスト観点図を囲んでいつでもみんながみんなのことをわかり合ってる状態だといいですね。テスト観点図に正解はないんです。大事なことは、みんなで育むことなんです。」

一足早く仕事終わったことを感じ取ったのか、鳥刈は雑談モードに入ったようだ。

「水元さんは、愛を育んでいるんですか?」

「もちろん。これから大事な人のために、クリスマスのプレゼントを買いに行きます。鳥刈さんは、クリスマスはどうされるんですか?」

「ぼ、ボクはカノジョとか軽薄な感じじゃなくて、一人で自宅で技術書読んでバリバリ勉強しますよ!最強のQAになりたいんですから!サンタさんにもお願いしてます!モテないんじゃないです!プロの独身なんです!」

自分で話を振っておいて狼狽するあたりを可愛いと言ってくれる女子は探せばいるんじゃないかな世の中広いんだし、とは口に出さず、片付けを終えて水元は立ち上がった。

「はっはっは。まぁ、無理しない程度にクリスマスを楽しんでくださいね。そうそう、テストエンジニアに恋人になってもらうといいですよ。色々気を配ってくれますから。ではお疲れ様でした。メリークリスマス♪」

To be, or not to be continued into the main story…


ISO/IEC/IEEE 29119シリーズに関する論争

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

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

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

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


Please sign this petition /
この請願に署名をお願いします

(訳注:このページは、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.

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


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を訪れてほしい。感謝する。


ISO 29119: Why is the Debate One-Sided? /
ISO 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の選んだ選択のようだ。


Response to Stop 29119 Petition /
「29119 Petition(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博士

 


境界値はテスト観点か

Twitterで2013/6/14で@akiyama924さんからご質問頂いたものをまとめておきますね。回答もTwitterで行ったので、140字ずつになっていますから、少し読みにくいかもしれませんが、ご容赦下さい。

にしさんには、テスト観点でない観点を何故それはテスト観点ではないのかといった理由とともに教えてほしいです。「意地悪漢字はテスト観点ではない」「同値はテスト観点ではない」等々の理由。その辺がもやっとしています。

 まず、同値はテスト観点ではない、というのは正確ではありません。同値クラスは(末端の)テスト観点ですが、境界値はテスト観点ではありません。境界値は、あるテスト観点のカバレッジ基準、もしくは選ばれた値そのものに過ぎないからです。全値、代表値、境界値などは全て同様です。

で、この説明を聞くとモヤモヤ感が高まると思います。

実はテスト設計における境界値というのは、2つの意味があるからです。1つは、同値クラスの主要な代表値としての意味。もう1つは、バグを如実に叩き出す武器としての意味。

テスト技法のセミナーを想像してみましょう。私の基礎コースもそうですが、同値分割の後に境界値分析を扱い、両者は関連があると教えることが多いですね。

しかしよく考えてみましょう。同値クラスというのは全て同じふるまいをする入力値集合です。しかし境界値とは、同じ同値クラスに属する他の値よりもバグを検出する確率が高いのです。ならば、境界値とそれ以外の値は、同じ同値クラスには属しません。なぜなら、ふるまいが異なると予想されるからです。

ここから論理的に帰結されるのは、実は境界値分析は同値分割と「意味的に」つながっていないということです。手順的につながっているだけです。言い換えると、境界値分析というのは同値分割に新たなテスト観点を加えているわけです。

もう少し正確に表現しましょう。同値分割は、入力条件網羅を行うためのテスト要求分析の技法です。境界値分析は、入力条件網羅のテスト詳細設計の技法です。これが一つの位置づけ。この位置づけを元に、NGTでは「境界値はテスト観点ではない」と取り扱います。

もう一つの解釈をすると、境界値分析はif文の比較演算子のミスや配列の境界越えのようなバグのパターンを示唆するテスト観点に基づき、テスト要求分析からテスト詳細設計までを統合した技法です。

この解釈を取るのであれば、境界値という曖昧なテスト観点よりも、むしろ「比較演算子のミス」をテスト観点として挙げた方が、モデリングが分かりやすくなります。ですのでNGTでは「境界値はテスト観点じゃないよ」という教え方をしています。

エキスパートの皆さんがモヤモヤしないように正確に表現するならば「境界値そのものじゃなくて、境界値で狙っているバグのパターンを直接テスト観点として挙げましょう。何のバグを狙ってもいない境界値は、単なる同値クラスのカバレッジ基準ないし値ですから、テスト観点ではありません」となります。

意地悪漢字も同様です。意地悪漢字が狙っているバグのパターンを直接テスト観点として挙げる方が、モデリングとして分かりやすくなります。

ただそれが難しいことも多々あるので、最終的にテスト観点に残さない前提で、他のテスト観点と組み合わせて考えるヒントとして、境界値や意地悪漢字が初期のテスト観点図に出てくる方がモデリングしやすい、ということであれば、別に構わないと思います。私もそうすることがあります。

あ、まだ疑問があったか、テスト技法はテスト観点じゃない、というやつね。

NGTでは、テスト技法はテスト観点じゃないという説明をしています。それは、テスト技法というのが何を意味しているか、に依存した説明です。より正確に言うと、一般的にテスト技法という用語が含んでいるものは、単純にテスト観点になるわけじゃないよ、という意味です。ヒントにはなります。

一般にテスト技法というのは、2つの工程をいっしょに行います。テスト要求分析すなわちテスト観点の特定と、テスト詳細設計すなわちテストデータの特定です。ただ面倒なのは、片方しかやらないテスト技法もある点です。

例えば境界値分析は両方やりますし、同値分割はテスト要求分析が主です。制御パステストはテスト詳細設計が主です。

テスト観点を挙げる時にヒントとなるのは、制御パステストのようにテスト詳細設計を主に行う技法です。なぜなら、テスト詳細設計を行うためにテスト観点を特定しているからです。テスト技法をテスト観点にすると、そのテスト技法で特定しているテスト観点を挙げていることになります。

ただall-pair法のように、テスト詳細設計を主に行うのにテスト観点を特定していないテスト技法もありますから、そう一筋縄ではいきません。ですのでNGTでは、テスト技法はテスト観点を挙げる際のヒントにはなるけれど、直接テスト観点にすべきではない、と説明しています。

一般に、NGTを教わるテストのモデラーはここまでテスト技法について考察しているわけではありませんので、ここまで詳しく説明するとかえって混乱を招くと予想されます。

要するに「テスト技法」という用語は、テスト要求分析とテスト詳細設計が分離されてなかった時代につくられた用語なので、テスト観点の特定とテストデータの導出の切り分けが難しい用語なのです。それが本件の原因。これは29119-4でテスト条件の粒度がずいぶん変わることからも分かります。


関連の方向性について

 2012/4/3に行われたWARAI(関西テスト勉強会)の受講者の方から頂いた質問です。

NGTはUMLのクラス図によく似た記述形式ですが、UML同様、関連に方向性があったりするのでしょうか?それともテスト観点に、依存関係の方向などなく、すべてフラットに抽出すべきでしょうか?(あるテスト観点と「その前提となるテスト観点」などは依存関係が存在しそうにも思えます。。。)

 ご質問ありがとうございます。まずお答えを先に申し上げてしまうと、関連に方向性をつけるかどうかはモデリングを行うテスト設計者が決めて構いません。

 ちょっと分かりにくいですね。NGTという記法としては、順序依存性を持つ関連に対して開き矢印で方向性を表します。一方、組み合わせテストの必要性のように方向性を持たない関連に対しては、矢印の無い直線で表します。また、関連の表す意味についてはステレオタイプで表します。WARAIではその辺りを詳しく説明する時間がありませんでしたね。申し訳ありませんでした。

 ところで、ご質問で気になるのが「前提となるテスト観点」という言い回しです。この「前提」とは、どういう意味でしょうか。もしこれが、回帰テストのように、Aというテスト観点から導出されるテストスクリプトを実施した後でBというテスト観点から導出されるテストスクリプトを実施する、という実施順序しか意味していないのであれば、その関連Xをテスト要求モデルに記述すべきではありません。その関連Xはテスト要求を満たすことに何も寄与しないからです。例えば、Bのテスト観点の必要性がAのテスト結果によって変化する(Aのテスト結果によってはBのテストをしなくてもよくなる、など)のであれば、テスト要求モデルに記述すべきです。もし、実施順序をそう定めることで実施効率を向上したいという意図があるのであれば、テストアーキテクチャ設計モデルに記述すべきです。これは記法の問題ではなく、モデリング技術の問題ですね。

 NGTの説明を聞くと記法に気を取られてしまいがちですが、モデリング技術も重要です。NGTはステレオタイプなど自由度の高い記法を指向していますので、皆さんがモデリングしたい構造を把握していればきちんと記述できます。ですので記法の限界を気にするよりも、記述しようとしている構造はどういう意味でどういう位置づけなのか、を考えることに時間を割くようにして下さい。そうすれば実り多いテスト開発が可能になると思います。頑張ってくださいね。