はじめに 〜何を文字起こししたのか＆なぜ文字起こしをしたのか〜
本記事は、にしさんによる「テスト設計コンテスト2013 関西地域予選 招待講演」の講演の一部を文字起こししたものです。
動画はYouTube上に公開されています。文字起こししたのは25:43あたりから40:40あたりです。
www.youtube.com
この講演は今でも全体的に価値のある話をしているなと感じているのですが、今回文字起こしした部分は、その中でも特に私が共感を持っている部分です。
今回の文字起こしした部分で、にしさんは「テストとは納得してもらうことである」という話をしています。これはにしさんが最期まで主張し続けていた考え方だと思っています*1。
この考え方に私も共感しているため、ことあるごとにこの動画を紹介しているのですが、人によっては長い動画を見るのが苦痛という人もいると思うので、そういう人に向けても広く知ってもらいたいと思い、文字起こししました*2。
なお、この文字起こしは、以下の1ページのスライドだけの説明をしています。以降、「おわりに」の前までが文字起こしの内容になります。
「ソフトウェアテスト技術（関西テスト設計コンテスト予選基調講演）」7ページより
目次
スタンス1：テストとは行動である
ある人は「テストとは行動である」と言っています。昔、偉い先生が言っていたことなんですけど、「テストでは何も証明できない、ただバグを見つけるだけである」まだこんな風に考えている人も、日本にはたくさんいます。まあ、残念ながら私に言わせれば1970年代から何も進化していないと言わざるを得ませんが。
こう言う方がいます。「テストとは行動である」。こういう方は「バグを見つけるためにテストを行う」なんて考えます。こういう方がですね、テスト設計すると何をするかって言うと、行動の内容と結果だけを提示するような、テスト設計をしたりドキュメントを作ったりします。さっきのこの部分「コピー＆ペースト＆モディファイ法*3」です。
スタンス1の会社と対峙した場合のよくある会話
「どんだけテストしましたか？」
「はい、8人で2ヶ月テストしました。」
「はい、それはどういう意味があるんですか？」
「はい、8000件テストしました」
「そうですか、それにはどういう意味があるんですか？」
「ええと、ええと、ええと、もう少しテストをしてほしいんだったらお金をください」
「いやいや、そういうことじゃなくて。はい、8人で2ヶ月テストしたから、だからなんなんですか？」
「いや、テストをしろっていう仕事じゃないですか。そういう発注ですよね？」
仕様書をもらいました、テストをしました、それで？みたいな会社が山ほどあるんですね。あの、微妙に頷いている方もいらっしゃって、ちょっとドキドキしているんですけど。
でですね、そういう会社は見つけたバグが全てだと思うあまり、「技術を向上しましょう」なんていう話をすると、どこの会社も組織も技術は向上させたいと思ってますから。
スタンス1の会社の探索型に対する理解
でも、このスタンスを取っている会社は、「いやー、今、探索型なんですよ。探索型。」
探索型のノウハウは…探索型って知ってますか？探索型というのは、ソフトウェアの微妙な振る舞いや一貫性のなさ、それからそのソフトウェアの使用やアーキテクチャに起因するであろう過去のバグのパターン、ソフトウェアの作り、そのテストが始まるまでの品質の状況、プロジェクトの混乱状況というか、様々な定量的もしくは定性的なデータを、人間が解釈して、バグの多いところを集中してテストする方法です。
今私は分かりやすく説明しましたよね。今の私の説明だったら、なんか技術が向上している気がするじゃないですか。それはなぜか。私が探索型テストの中身を剥離したからです。
スタンス1の会社で、つまり「テストとは行動である」と認識している会社で、分かってやる探索型テストっていうのは、
「ゴットハンドっているんだよね。ゴールドフィンガーっていうのかな。手から電磁波が出ているんだよ。バグがたくさん見つかるんだよ。なんでかね、ちょっと知りたいんだけどね、なかなか口割ってくれないんだよね。」
手から電磁波出ていません。断言します、出ていません。ごく微量のコンピュータに影響を与えない電磁波はどの人間からも同じように出ています。しかし、ある人が特にバグを見つけやすい電磁波を出すことはありません。論理的に、科学的にあり得ません。
ですから、そこにはなんらかのノウハウが必要ですが、「テストとは行動である」と、とにかくテスト行為をすれば良いんだと思っているような会社組織さんの場合は、残念ながらそこからはもうですね…。
スタンス2：テストとは説明である
ですからもうちょっとマトモな会社さんはこう考えます。「テストとは説明である。」「テストとは仕様通り動くことを実証することである。」なんて会社さんがいらっしゃいますね。その通りなんですよ。その通りなんですけど、じゃあどうやって説明するか。
スタンス2の会社と対峙した場合のよくある会話
まず最初に説明するのは、「我々はこれをやりました。このテストケースをやりました」これは別にスタント1の会社と一緒ですね。
「ここからここまでのテストをしました。」
「それはどういう意味があるんですか？」
「はい、仕様書の要件を100％網羅しました」
「だからなんなんですか？」
「いや、仕様書の要件を100％網羅しました。これで仕様書は全部検証できます」
「もしもバグがあったらどうするんですか？」
「いやだって、仕様書の要件を100％網羅したんだから、それでもバグがあるんだったら、うちのテスト漏れでない限り、それはウチの責任ではありませんよ。」
説明無責任
説明責任という言葉をご存知です？説明責任というのは、自分がやったことを他人に説明しなきゃいけないっていうことだと思われていますよね。しかし、ビジネスもしくは技術の低いビジネスの場合だと、説明責任というのは往々にして、説明無責任という状況を生み出します。説明無責任とはなんなのか。それは、責任を取りたくないがために、「自分たちに責任はないよ」という説明を尽くす現象のことです。これを説明無責任と言います。
なぜテスト会社は工数請負をするのか
皆さんの中で、テスト会社さんはいらっしゃいますかね？もしくはテスト会社さんと付き合いのある会社さんはいらっしゃいますかね？こんなこと思ったことはありませんか？
「なんでテスト会社って格安、安い単価で時間契約するんだとか工数請負契約するんだろう？」
「そんなことしなくて、バグを何件見つけたら、それに応じてボーナスを払われるそういう契約にすれば良いのに」
って思ったことありません？私、テスト会社にいたので分かるんですが、そんな契約怖くてできないんですよ。バグを見つけてたらボーナスをもらえる契約にするということは、同時に、バグを見逃したらペナルティっていう契約になるんです。
そもそも開発の質が悪かったらバグは全部見つけられないんですね。まあ、開発の質が良すぎても見つけられないんですけど。なかなか難しいんですけど。なわけで、テスト会社はテスト漏れがあったときに自分たちがダメージを負うようなリスクを取れない。違う言い方をしますね。テスト会社は品質を保証したくないんです。リスクが高すぎる。だから彼らは何をするか。工数請負をします。
説明責任を目的にすると説明無責任を生み出す
しかし、それでもお客さんに「大丈夫？大丈夫？これで全部？」って聞かれます。お客さんは勝手なもので、自分たちがテスト会社とする契約形態に関わらず、お客さんはお客さんで自分に責任がないようにしたいんですよね。自分の上司に対して、「いや、なんとかっていうなんかテスト会社に頼んだから、もうバグがないと思いますよ。だってあそこ専門家ですし。」ってね。だから、お客さんも説明無責任の連鎖に入る。そうするとテスト会社は、無責任の連鎖の最下層にいますから、責任を被らないために、
「いや、お客様がテストをしろとおっしゃったのはこの仕様書で、この仕様書を一文一文分解すると、これだけの要件になって、この要件はトレーサビリティのある表を使うと、こっからここまでの表で全部なんです。で、この表を全部我々の会社のテスト法では、お客さんが言っている限りないはずです。それに、一つ一つレビューしていただきましたよね。レビューしていただいて、問題はなかったですから、OKなはずですよね。」
けど、お客さんはこう思ってます。
「いや、レビューしろと言われたけど、いきなりなんかこうエクセルのシートで160枚とか送りつけられて明日までとか無理じゃん。OK出すしかないわ、うちも仕事を遅らせたくないし。」みたいな回答になるんですね。これを説明無責任と言います。
説明することが目的になっているテストは、説明無責任を生み出します。そうすると、そこに質の向上というのは現れにくくなる。なぜなら、お客さんの言っていることに従うことがこの説明無責任の最終目標だからです。自分たちに責任を負わないためには、お客さんが言った通りにやるんです。それが最適解なんです。仕事上でやるには。
「テストとは説明である」というスタンスだと創造性のないテストになる
だから、スタンス2を取っている会社さんというのは、いろんな技術を使うんだけど、結局お客さんに従うっていうスタンスになるので、創造性が全然ないテストになるんです。ひたすらなんか表を埋めるんです。表を作って、表を埋めて、表を作って、表を埋めて、表と表の間の関係を1つ1つ潰していって、エクセルのセルを埋めて線を引いて、表を埋めて線を引いて、表を埋めて線を引いて、チェックつけてチェックつけてを繰り返していきます。だからうんざりするんです。できた成果物も表ばっかりです。
スタンス3：テストとは納得してもらうことである
しかしですね、世の中には良いテスト会社、良いテスト組織ていうのもあって、そういうところはスタンス3「テストとは納得してもらうことである」っていう。納得するために、技術と知性とまごころを尽くして説明する。これはどういうことか？スタンス2と何が違うのか。
納得してもらう説明をするためにモデルを作る
さっき、昨年のテスト設計コンテストの成果物の話をしましたね。説明をするだけならこの表で十分です*4。（筆者注：この部分は別のスライドが投影されているので、詳しく知りたい方は動画を見てください）我々、これをやります、この表をお客さんに修正してもらっています。でも彼らはわざわざ、お客さんの仕様書にはないこんなようなモデルを作るわけですね。こんなのを作ったら、スタンス2の場合、リスクを負うことになります。「なんで自分達でこんな勝手になんかやったりしてんだよ。」「こんなのはウチの仕様書にないぞ」と言われたら終わりじゃないですか。でも彼らはわざわざこういうモデルを作る。なぜなのか。こういうモデルを使った方が説明しやすいからです。
これ*5、テスト何種類あるか分かりますよね。この個々の種類、例えば青とオレンジの間の関係、この黄緑の中のえー‥1・2・3・4、5つの箱、5つの箱の関係がパッと見て取れますね。じゃあこっちどうですか？何かがパッと見て取れますか？埋まっているか、埋まっていないか、いっぱいあるかないかしか分からないんですね。結局のところは。「いや、そんなことないよ、よく読み込めば分かるんだよ。」読み込めば読み込むほど、全体が分からなくなりますね。
分かりますか？これが説明と納得の違いです。説明をするというのは、相手がちゃんと納得することを意味していないんです。説明したからと言って、相手が納得するとは限らない。だから大事なことは、相手が納得するようなテスト設計をちゃんとできること。
スタンス3の会社と対峙した場合のよくあるコミュニケーション
「これがテストの全体像です、一緒に検討していただけませんか。」分かりますか、言っていること。「これが僕らの表です、これで良いですね」じゃないですよ。一緒に検討していきたいんです。お客さん時間ないですね、お客さん忙しいからウチに仕事が入って、我々に仕事を下さって。
じゃあ、お客さんが一緒に検討してくれるようなそういうドキュメントってどんなドキュメントですか？お客さんが短い時間で全体や我々のやりたいことを把握してくれて、お客さん自身が抜けが気付いて、我々にそれを指摘してくれやすいようなドキュメントってどういうドキュメントですか？160ページのエクセルシートじゃないですね。せいぜいA3 1,2枚の図です。絵です。こういったものをきちんと作るのか。
スタンス3は選択肢を提示する
それから選択肢ですね。テスト会社は「これをやりました、もっとやってほしければお金をください」これがスタンス1です。お客さんがほしいのはそうではありません。
お客さんの仕事をうまくやるためには、
「4つの選択肢があります。1番の選択肢を使うと、お金はもっとかかりますけど、こういうところはきちんと品質を保証できます。2番目の選択肢は予算通りに仕事を終えます。でも、ココとココに抜けがあります。選択肢3は、お客さんの予算より安くできるようにします。お客さんが言ったことは全部網羅しますけど、お客さんが言っていない、こういう組み合わせとか、こういう深い話はちょっとテストできないです。4番目は、お金はかからないんですけど、お客さんが我々に開示しない設計の中身やコードの中身を開示してください。そうすれば我々はより高い技術を使って、予算内でもっと多くの品質を保証してみせます。」
こういう選択肢を提示して、個々の選択肢のメリット・デメリット、およびそれができる理由をきちんと説明する。そうすれば、お客さんは納得して、お客さんが選べますね。
会社のスタンスがテスト設計の質の向上の成果を左右する
こういう仕事のやり方をできるような技術を捉えているか。それが重要になります。自分たちのテストに対するスタンスがきちんと分かっていないと、残念ながらテスト設計の質を向上する取り組みに工数をかけても、スタンス1,2の場合には、3に比べて結果が得られません。
おわりに
今回は、にしさんの講演「テスト設計コンテスト2013 関西地域予選 招待講演」の一部を文字起こししてみました。
講演の中の15分程度の動画の文字起こしをしましたが、全体が興味深い講演になっていますし、何よりもにしさん節が炸裂しているので、本記事を読んで興味の持った方はぜひ、にしさんの動画も視聴してみてください。
