「テスト観点はふんわりね」

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

著者: にし やすはる

「それはさぁ、テスト観点というよりも目的機能なんじゃないかな。いやお前の言うことは分かるよ、論理的機能構造に照らし合わせるとテストカテゴリだって言うんだろ?でもさぁ…」

年末のシアトル系コーヒーショップの簡素な丸テーブルを挟んで、若い男性が激論を交わしていた。イマドキの若者らしく、手元のPCにはこれでもかとステッカーが貼ってある。その横では、スリーブの付いた大きめの紙カップが存在を忘れられたかのごとく議論を見守っている。混みあった店内は7割がカップル。残りは意識の高そうなエンジニア。年末らしく店内にはちらほらと赤や緑の装飾が見え隠れする。フランク・シナトラが大きな歌声でクリスマスを祝っている。

親友。鳥刈は目の前の男性で口角泡を飛ばす若者をそう思っている。自分よりセンスのよい服装。自分よりセンスのよいメガネ。自分よりセンスのよい人の多そうな職場。出会ったときはボサボサの天然パーマだったが、最近はなんだかエリアーだっけ?エアリーだっけ?アリエールだっけ?そういうセンスのよい髪型になってきた。やっぱり職場環境って大事だ。いいなぁ。でも自分は彼にコンプレックスを感じることなく話ができて、議論もできる。学校も違う、会社も違う。生まれも違う。でも親友。年末に彼女とクリスマスデートなんてしなくても、こうして親友と技術の議論ができるだけで自分は幸せ者だ。そう思いながら鳥刈は目の前の「親友」との議論に没頭していた。

顔見知り。古里は目の前で要を得ない若者との関係を他人に説明できずに困っていた。住所は知らない。電話番号も知らない。年賀状もやりとりしない。学校も違う。会社も違う。生まれも違う。だから顔見知り。本名だって時々忘れてしまう。実家の親にどんな人かを根掘り葉掘り聞かれた時に答えられないのであれば、友達とは言えないのではないか。平成と昭和の狭間に生まれた自分でも、それくらいの伝統的考え方はある。でもSNSで毎日ガンガン会話をする。勉強会で毎週会って毎回呑みに行く。こうやって土日に二人で会って技術的な議論をしたり会社のグチをこぼし合う。高校のクラスメートよりもよっぽど彼のことを知っている。でも別に関係なんて他人に説明するもんでもないし、そんな機会もない。仲が良いという事実だけでいいじゃないか。それが合理的だ。そう思いながら古里は目の前の「顔見知り」との議論に没頭していた。

             ☆                  ☆

休日出勤かぁ。この業界にいるとしばしば遭遇する。自分の仕事をどんなにカンペキにこなしたとしても発生する。分かってはいるから怒らないけど、待ち合わせの夕方までどうやって時間を潰すか。水元はヒマをもてあましていた。クリスマスプレゼントは昨日買ったから商業施設巡りも必要無い。一人でラブストーリーを観てもしょうがない。お腹はそんなに減ってない。身体を動かすほどの時間はない。ないない尽くしの休日の昼下がり。コーヒーを飲むほど喉も渇いてはいないのだが、座ってヒマつぶしを考えるための場所代を払わないと行くところがない。全てが消去法で決まっていく状況。この状況を水元は好まない。そういう状況に嵌まっている現場を導くのが彼の仕事。いつのまにか消去法を嫌がる体質になってしまった。よし、書店が併設されているコーヒーショップに行こう。本を読んでもいいし、雑誌を買って物欲を増幅させてもいい。何なら久しぶりにパズルに没頭してもいい。選択肢は多いほどいい。本当のところコーヒーを飲むことと本を読むことの二つしか選択肢は無いのだが、水元は自分にそう言い聞かせると少し上機嫌でシアトル系コーヒーショップに入っていった。

コーヒーの種類、ホットかアイスか、サイズ、シロップの種類、それ以外にパラメータは何があるんだろう。エスプレッソのショットを増やせたっけ。あぁデカフェにもできたな。そう言えば自分はいつも豆乳だ。ついつい組み合わせを考えてしまうのはやはり職業病だ。年末のシアトル系コーヒーショップは賑やかで、カップルが多い。聞くとはなしに店内の会話に耳が向くと、急に頭の中のS/N比が変わった気がした。聞いたことのある声が、聞いたことのある単語を発している。誰だ…、いや誰とかじゃない。昨日会った若者だ。水元はスマートフォンの名刺アプリを開いた。鳥刈さん。そう、そんな名前。将来有望、かな?ともかく、元気な若者だった。クライアント先でいつもの担当の方がお休みだったので、代わりに質問してこられたのだ。観点の蒸留の話をしたけど、分かってくれたかな。いやいやちょっと待て。今日は休日で今はプライベートだ。仕事の話はしないぞ。しない。絶対にしない。だって今日は休日だから。休みをきちんと取らないと、よい仕事ができない。だから鳥刈さんに見つからないように店を出よう。そうだ、そうしよう。水元はその直前までコーヒーの組み合わせについて考えていた自分のことをすっかり忘れ、コーヒーを受け取るべくオレンジ色のランプの下まで大股で移動した。

             ☆                  ☆

「あ、水元さんだ。鳥刈、あの人知ってる?テストのコンサルタント。前に講演を聴いたことがあるんだ。」

古里は目ざとく、コーヒーの受取口に向かった水元を見つけた。鳥刈は聞いた名前だなと思いつつ身体をねじると、昨日親切に色々教えてくれた優しいコンサルタントさんが目に入った。知ってるとも、と誇らしげに言うが早いか、鳥刈は水元のところに向かった。

「水元さん、昨日はありがとうございました。今日はどうされたんですか?お一人ですか?もしよろしければ、一緒にいかがですか?」

あー、見つかった。水元は自分の運の悪さを呪った。なんでこの店に入っちゃったんだろう、なんでコーヒーなんか飲もうと思ったんだろう。そうだ、休日出勤なんかするからだ。でも彼女が悪いわけじゃないし。やはり運が悪いのか。朝の星占いは何位だったっけ。そうか今日は休日だから…。いやいやそんなことを考えていてもしょうがない。どうせヒマなんだ。少し世間話でもしながら、頃合いを見て場所を移そう。

「こちらこそ、昨日はありがとうございました。奇遇ですね。せっかくですので、ご一緒させて頂いてもよろしいですか?」

腕のよいコンサルタントは、休日でも優雅だ。突然なのに受け答えも優雅だ。自分はこんな凄いコンサルタントに昨日付きっきりで指導を受けたんだ。鳥刈はなんだか嬉しくなって、自分のテーブルに急いで戻って他のテーブルから余っている席を運んできた。

海老と蟹。家を出る前に耳に入ったピザのCMのせいか、反射的に水元はそう感じた。瓜実顔の鳥刈さんは海老。もう一人の初対面の同じ年の頃の若者は蟹。仕事柄出会う人が多すぎるので、こうやって何か別のものを連想すると覚えやすいという法則が身体に染みついている。水元は用意された木製の簡素な椅子に座ると、蟹の方に向かって自己紹介した。蟹が古里と名乗ったところで、鳥刈が蟹は以前天然パーマで見るからにブロッコリーのような風貌だったと口を挟んだ。余計な情報を笑顔で受け流すと水元は聞いた。

「お二人は、お友達ですか?」

「親友です」「顔見知りです」

鳥刈と古里は同時に答え、お互いの顔を見合わせた。鳥刈は驚いた顔を、古里はバツの悪そうな顔をお互いに見せた。おっとまずいな、水元は直感して言葉をつなげた。

「ある人にとって親友という仲の良さであっても、別の人にとって顔見知りと表現されることはままあることです。大事なことは、こうやって年末の休日に二人で仲良く話していることだと思いますよ。私の言葉遣いでは、お二人は『とても仲の良い友達』だと思います。合ってますか?」

古里はホッとした顔で頷いた。鳥刈は嬉しそうに何度も頷いた。

「自分の使っている言葉と他人が使っている言葉というのは、常に異なるものなんです。だからまず大事なのは、自分の理解。次に、自分が理解したものを自分はどういう言葉で表現するか。そして最後に、自分が理解したものを他人はどういう言葉で表現するか、をマッピングすることです。この順序を逆にすると痛い目に遭います。自分があまりよく理解していないうちに他人の言葉を借りて表現しようとばかりすると、余計に混乱するんですよ。そういう経験、ありません?」

水元がすっかり仕事モードで話をまとめると、二人は同時にこう叫んだ。

「そうなんです!ちょうど今それで困ってたんですよ!」

             ☆                  ☆

欧米人は何かをすする音が大嫌いだ。日本人とは違ってスープや麺も音を立てない。自分もレストランでスープを飲むときは音を立てないようにする。でもカップの蓋のこの小さい穴から熱いコーヒーを冷ますように飲むときだけは音が出てしまうのではないかな。音が出るのは一すすり目かな、それとも一すすり目と二すすり目の間かな。音が出る時の唇の上下動はどのくらいだろう。水元が集中を始める時の癖だ。周りの音が遮断され、その時気になっていることが頭を占める割合が上がっていく。視野はどんどんミニマルになる。感覚が研ぎ澄まされていく。頭の中がクリアになっていく。概念を扱うモード。問題を解決するモード。いまにも問題にダイブしようとするモード。心地よい状態遷移。

「何に困っているんですか?」

水元はミニマルな質問を投げた。

「昨日コンサルティングを受けて、その時はテスト観点について分かった気がしたんです。でも今日古里くんと話しているとやっぱり分からなくなっちゃって…。テスト観点とかテスト条件とか目的機能とか論理的機能構造とかテストカテゴリとかテストレベルとかテストタイプとか色々あるじゃないですか。話せば話すほど混乱してくるんです。分からなくなってくるんです。答えが欲しいんです。だってそうじゃないですか。答えが無いのにどうやって仕事…」

「待て、鳥刈。落ち着け。ゆっくり話そう。」

左手で鳥刈の言葉を制しながら古里は続けた。

「テスト観点って、何ですか?」

             ☆                  ☆

水元は快適な集中から一気に現実に引き戻された。鼓膜に周囲の喧噪が直接響いてくる。急に頭の中にもやがかかった。だーかーらー昨日言ったでしょ。胃の辺りから喉の上辺ギリギリまでその言葉が上がってきたが、無理矢理押し留めた。よいコンサルタントの法則、第一条。コンサルタントは迂闊に物事を判断してはならない。うん、大丈夫。落ち着け。昨日のことをきちんと思い出そう。昨日したのはテスト観点の蒸留の話だ。その時にテスト観点はテストケースの意図であるという説明を何度もしたはずだし、鳥刈さんも深く理解していたはずだ。ともあれ、もう少し詳しく聞いてみよう。

「ふむ…。よい質問ですね。もう少し詳しく教えてもらえませんか?」

鳥刈は見惚れた。ゆったりとした仕草。柔らかな微笑み。ほんのり立ち上ってくるいい香り。自分たちが散々話しても分からなかったことなのに、きっとこの人には当たり前すぎることなんだろう。自分もこんな凄い人みたいになりたいなぁ。おい奥村くん。こんなことも分かんないのか。先輩のくせに情けないぞ。毎日家に帰らずに酒ばかり飲んでいるからだ。あぁ安達部長。それはこのようにすればカンペキですよ。この部署はやはり私がいないと回りませんね。はい社長、新しいビジネスのアイデアなら…。

質問に質問で返すのか、この人信用ならないな。古里は警戒した。大体コンサルタントなんてものはインチキだって相場が決まってる。現場で手を動かす技術者の言うことじゃないと裏付けが無い。テストケースを書いて書いて書きまくった先にこそ真実があるんだ。気をつけて話をしなきゃ。向こうのペースに乗ってはいけない。百戦錬磨の営業マンなんだ。騙されちゃいけない。少し語気を強めて古里は繰り返した。

「だから、テスト観点って、何ですか?」

休日に人を突然巻き込んでおいて対話の意思を示さないのか。若さって素晴らしい。若さって傲慢だ。若さって暴力的。この若さが、彼らを成長させる原動力になると祈ろう。今は問題に集中だ。この手合いは、単純に定義を示しても納得しない。おや、昨日も同じことを思ったぞ…。

『この質問に答えはないからだ。なぜ答えがないのか。質問者は字面としてテスト観点の定義を質問してくる。しかし実のところ彼らが聞きたいのは「良い」テスト観点の挙げ方であり、それが「良い」ことの保証である。質問にまともに答えるとずいぶん哲学的な定義の話になるし、モヤモヤは消えず不承不承納得した表情をして話は終わりになる。誰も得をしない。だからといって「良い」テスト観点について答えるのも難しい。結果として得られたテスト観点の良し悪しよりも、そこに至る過程でどこまでケンケンガクガクあーでもないこーでもないと議論して、時には白熱して、そして皆が納得感を共感することが大事だからである。誰かから「良い」テスト観点をもらってきたとしても、すぐに陳腐化する。水元はそのことをよく知っているし、少なくないエネルギーを費やしたコンサルティングの成果がクライアント側で水の泡になってしまって臍を噛んだこともある。どうしたものか...。』

             ☆                  ☆

「テストケースの意図、と昨日説明した気がするんですが…。」

よいコンサルタントの法則、第二条。コンサルタントは微笑みを絶やしてはならない、クライアントにどんなに失礼なことを言われようとも。水元は88%の微笑みと10%の困惑、そして2%の叱責からなる表情で鳥刈に問いかけた。

「は、はい。それは言えます。テストケースの意図ですよね、テスト観点って。昨日たっぷり説明して頂きました。ありがとうございました。」

「いえいえこちらこそありがとうございました。そうすると、どの辺りが悩みどころですかね。人間というのは、どんなことであっても聞いてすぐ本当に理解したりはできません。ですから、そうやって悩まれているのはとても自然なことだと思いますし、より深く理解しようとしているわけなので素晴らしいと覆いますよ。古里さんとは、どの辺を議論していましたか?」

「目的機能とかテストカテゴリとか、似たようなものが色々あるじゃないですか。テスト観点との違いが分からないんです。テストタイプとかテストレベルとの違いも知りたいです。ラルフチャートとか論理的機能構造とかとの関係も興味があります!」

将来広辞苑がVRで読めるようになったらドヤ顔の項目にはこの顔が出てくるだろうな、と古里は思った。どうして質問をしているのにそんな誇らしい顔ができるんだろう。分からないことは、恥ずかしいことだ。分からないなんて他人に言いたくない。悔しい。

「分かるには分かるんすけど、なんかしっくり来ないというか。モヤモヤしてるんすよね。いや分かるんすよ。でもなんか念のため聞いておきたいというか、そういう感じっすね。」

古里の語尾の敬語が崩れてきていることを水元は聞き逃さなかった。古里の上半身がやや後傾になったことを水元は見逃さなかった。多分そんなこと思っていないんだろう、古里さんは。防御的な心理を隠すための親密さ。クライアント先への初回の訪問で現場の問題を尋ねた時の返答でよく体験する。対応を間違えるとこじれてしまう面倒くさいパターンだ。水元は細心の注意を払いながら、古里を受容するメッセージを発した。

「そうですよね。分かっているのに、分かったような分からないような、そんな感じになるのが普通です。自然ですよ。当然です。分かっているからこそ、の感想ですよね。」

ほんの刹那、息を深く吐いた。防御的態度が需要されたことの安心感だ。この人は自分を評価してくれている。古里は少し肩の力を抜いて謙遜した。

「いや分かっているなんて言われると困っちゃいますけど、鳥刈よりはマシかな、なんて思います。」

「えー、古里も分かってないと思ってたのになぁ。裏切り者。」

仲いいな。水元はいちゃいちゃし始めた若い男性の様子を懐かしく思った。自分も学生の頃はそうだったな。

「どうして違いが知りたいんですか?多分、理解したいんですよね。新しい言葉や聞き慣れない用語を聞くと、理解したくなる。自然な感情です…」

「そうですそうです。理解したいんです!」

水元が言い終わる前に、鳥刈は縦に大きく首を振りながら言葉をかぶせてきた。

「分かった分かった、落ち着け鳥刈。」

古里は左手で鳥刈を制しながら、まなざしで水元に続きを促した。あまりにもスムーズな二人の掛け合いは既に伝統芸能だ。

「でもそれは、あまり役に立ちません。知識をたくさん仕入れて他人に自慢したいのであれば別ですが。お二人は、自慢するために理解したいのではありませんよね?」

二人は同時に、同じ角度で同じ大きさでかぶりを振った。

「よいテスト設計をしたいんです。できれば自分の職場で、それぞれのいいとこ取りをして活用したいんです。だから、色々知りたいんです。」

古里は真面目な面持ちで答えた。これは本心だ。

「なるほど。いいとこ取り。確かに魅力的ですね。ではひとつ質問しましょう。和食と中華とフレンチのいいとこ取りをして新しい料理を生み出せるのは、どんなシェフでしょう。和食も中華もフレンチも、どの料理も作ったことの無いシェフですかね?そんなわけはありません。まずどれか一つに精通した上で残りを学んでいくからこそ、いいとこ取りができるわけです。どれも中途半端であれば、できるのは単にレトルトを混ぜ合わせただけの紛い物です。」

「レトルトの混ぜ合わせですか…。それは嫌ですね。せっかくだったら本物を作りたい。」

「嫌です嫌ですレトルトなんて。僕レトルト苦手なんですよ。インスタントもあんまり得意じゃないんです。油っぽいし。」

「鳥刈、それはちょっと違う話かな。ちゃんと水元さんの話を聞けよ。」

古里は苦笑しながら続けた。

「ということは、違いを知りたいのは意味が無いということですか?」

「それぞれの定義を字面で比較したところで、よいテスト設計にはつながりません。でもそれぞれのテスト設計の方法論を活用した上で、それぞれの弱点を他の方法論で補完できれば、よいテスト設計につながりますね。そういう意味です。」

「じゃあどの方法論から始めればいいですか?」

鳥刈はポジティブでアクティブだなぁ。あいつは安直だからもっとよく考えるべきだ、なんて批判する人もいるが、色んなことを考えすぎてつい後手に回ってしまう自分には足りないところだ。素直に見習わなきゃ。古里は心の中で敬意を表しながら、水元の答えに耳を傾けた。

「好みです。どれでもいいんですよ。ただ大事なことは、方法論を学ぶだけで終わらずに、必ずテスト設計をしてみること。何度か繰り返してコツを掴み、自分の最初のテスト設計とコツを掴んだ後のテスト設計とをレビューして比較して、どの辺が成長したのかを読み取るといいですね。お二人のように、友達同士で比較してもいいでしょう。もちろん、その方法論を使う前と、使ってみてコツを掴んだ後とで比べても構いません。成長したところが、きっと、その方法論の得意なところです。」

「古里、やろうよ。」「面白そうだね、鳥刈。」

             ☆                  ☆

「例えばテスト観点を使う方法論の場合、最初は機能ばかり挙がります。いわゆる非機能は申し訳程度にしか挙がりません。」

「そういうテスト観点リストを配っているサイトもありますね。」

「でも最初はそれでいいんです。そういうテスト観点図を描いたら、次に自分でレビューしてみましょう。作ったテスト観点図だけを見ていてもよく分かりませんから、『もしテスト観点図を使わないとどんなテスト設計をするか』と想像してレビューするとたくさん問題点を見つけられます。例えばお二人なら、どんな風にそういうテスト観点図を成長させますか?」

「SQuaREシリーズで品質特性を網羅します!ISOで決められた国際規格ですから、それを使えばバッチリですよ!」

鳥刈の眼が輝いた。勉強の成果を活かせる場面が来た。たくさん勉強したんだ。でも会社の人たちは理解してくれない。奥村先輩なんていつも「鳥刈、勉強だけじゃダメなんだぞ」とか言って呑んでばかりいる。でも違う。僕が正しいんだ。勉強したことを実務で活かすんだ。

「SQuaREを参考にするのはよいことですね。でも気をつけないといけないのは、SQuaREも他の国際規格も完璧なものは無いですし、きちんと意味を理解して使わないといけないという点です。国際規格だから網羅されている、というのは正しくありません。国際規格は議論と投票で決まりますからね。」

鳥刈の目が泳いだ。水元は気にせず続けた。

「SQuaREの製品品質では主に外部から観測できる品質特性を扱っていますので、性能やセキュリティといったテスト対象の“ふるまい”を評価したいという意図のテスト観点を挙げる時に便利です。期待結果をしっかり考慮してテスト設計したい時にも、私は品質特性と一緒に“ふるまい”としてテスト観点を挙げますね。」

             ☆                  ☆

「性能テストと負荷テストって、どう考えたらいいですか?」

古里は尋ねた。

「よい質問ですね。例えば性能テストの時には、負荷をかけた時の性能低下を検出したいことがあります。でも負荷をかけない通常時の性能を測定したいこともあります。負荷テストの時にも、負荷をかけた時の性能低下を検出したいことがあります。負荷をかけてシステムがダウンしてしまうかどうかだけをテストしたいこともあります。」

「なんだかこんがらがってきました。」

「そうなんです。“~テスト”というようにくくってしまうと、一体どんな意図でテストしているのかが分かりにくくなってしまいますね。“~テスト”というのを一般的に、テストタイプと呼ぶのは知っていますね?そうすると、何が欲しくなりますか?」

「テストタイプとテスト観点との対応表です。どのテストタイプにどのテスト観点が含まれているのか、を整理したいです。」

古里は勘がいい。

「そうですね。Excelが好きなら対応表でもよいでしょう。モデリングツールが好きなら、包含関係を表すモデルを描いてもいいと思います。私は“テストコンテナ図”と呼んでいます。」

「コ、コンテナ?また新しい言葉が出てきた。覚えなきゃ。定義を教えてください!」

知識欲モンスター鳥刈が食いついた。

「別に難しい話ではありませんよ。機能テストって聞いたことあります?」

「えぇ。テストレベルの一つだったりそうじゃなかったり。」

古里が答えた。

「鳥刈さん、品質特性の一つに似たようなやつありません?」

「ありますありますあります。機能適合性です。機能完全性と機能正確性と機能適切性から構成されます。」

鳥刈が誇らしげに答えた。

「一般論として、品質特性を評価するような“~テスト”はテストタイプですよね。では機能適合性を評価する“機能テスト”があったとしたら、それはテストレベルですかね?それともテストタイプですかね?」

水元の微笑みが意地悪そうなものに変わっていたことに、鳥刈と古里は気付く術も無かった。

「機能テストはテストレベルだけど、機能適合性テストはテストタイプで…」

鳥刈の顔が混乱で赤くなり、いまにも湯気が出そうになっている。古里は数学の期末テストに答えるような顔で言った。

「解けません。解が二つあります。テストレベルでもあり、テストタイプでもあります。まるでシュレーディンガーの猫ですね。」

「はい。量子力学のように存在確率の雲を定義するわけにはいきませんから、いっそのことテストレベルとテストタイプを区別するのを諦めてしまえば話は簡単になります。そこで“テストコンテナ”という新しい用語が出てくるわけです。ついでに、テストサイクルとかテストラウンドとかそういうのも含めてしまえと。テストコンテナは、テスト観点をひとまとめにしただけのものだと考えておけばよいでしょう。この話は“テストアーキテクチャ設計”につながりますので、長くなります。今日は踏み込まないでおきましょう。」

「テストアーキテクチャ!それも分からないんです。でもなんだかカッコイイですよね。テストアーキテクチャ。テストアーキテクトになってみたいんですよ、将来的には。僕のキャリアパスの一つなんです。」

いまの赤さは興奮の色のようだ。鳥刈には興奮の種が尽きない。水元の微笑みが優しさに戻った。

「テストコンテナがどんなテスト観点を含むかという情報は、普通はテスト計画書に文章で書かれます。でも文章だと抜けが出やすいですし、類似のテストプロジェクトから丸ごと流用されやすい部分でもあります。対応表なりテストコンテナ図をつくって、きちんと検討できるようにしておいた方がよいですね。」

             ☆                  ☆

「話を戻しましょう。性能はふるまいでした。では負荷はふるまいですか?」

「いいえ、負荷はふるまいじゃないですね。なんだろう、条件かな?」

古里は答えた。

「では“条件”と呼びましょう。さっき最初に作ったテスト観点図にはふるまいの他に、負荷とかタイミング、長時間稼働などといった“条件”を表すテスト観点が足りないことが分かりましたね。他にはどういう種類のテスト観点があるでしょう。鳥刈さん、お腹は減ってませんか?」

「そういえば、おなか空いてきました。古里、晩ごはん何にする?」

「肉。オレ、野菜は嫌いなんだ。特にブロッコリー。」

「お二人の献立は後でゆっくり決めて頂くとして、鳥刈さんはいまお腹が減っているという“状態”にあるわけです。異なるドメインのテストに携わると分かりますが、テスト対象を表現する方法はいくつもあります。機能で表現する方法が一番ポピュラーですかね。ソースコードやクラスといったソフトウェア構造で表現する方法も有名です。組込みでは状態遷移で表現することも多いです。制御式や通信シーケンスで表現することもあります。ハードウェアの構成やネットワークが含まれることもありますね。テストではそれぞれのテスト対象の構成要素を網羅したり、怪しい構成要素を選んだりします。つまりこういった“テスト対象”もテスト観点の一種になるわけです。」

「テスト対象の表現って、色々あるんですね。」

「テスト設計をする時に機能を考えるというのは大事なことですが、機能さえ網羅していればテストが十分なわけではありませんし、機能に頼りきったテスト設計をすると機能以外を漏らしてしまうかもしれません。」

「確かに機能と非機能という構造のテスト観点リストを見た時に、状態が色んな機能に散在していて、これで網羅できるのかなと思いました。」

「だったらむしろ、状態というコーナーを作ってまとめてしまう方が挙げやすいし、読みやすいですよね。というわけで、テスト観点にはふるまいと条件の他に、テスト対象というのも含まれることが分かってきました。ところで古里さん、ブロッコリーは嫌いなんですか?」

「えぇ。なんだか食べてるとゾワゾワしてくるんです。」

「共食い?」

「共食い言うな。」

ブロッコリーというより蟹だろう、と言いかけて水元は口をつぐんだ。よいコンサルタントの法則、第三条。コンサルタントは余計なことを言ってはならない。

「嫌なもの、って誰にもありますよね。開発でもあります。バグにつながりやすい仕様や設計。怪しいソースコード。作り込まれやすいバグのパターン。お金が失われたり怪我をしたりといった絶対に起きて欲しくないこと。こういうのを狙ってテスト設計をすることも多いですね。ならば、テスト観点として挙げましょう。」

「なるほど。探索的テストとかに役立ちそうですね。」

「ここまでで四つの種類が挙がりました。他にもありますよ。ゲームなんかですと、重課金ユーザなのかライトユーザなのか、その生活サイクルはどうか。どういうビジネスモデルで運営をするのか。つまりテスト対象の周りの“世界”に焦点を当ててテスト設計をするわけです。色々ありますね。」

「ホントです。テストって、奥が深いですね。」

古里は感心しながら言った。

「別にこのCIBFW、“条件(Condition)”、“テスト対象(test Item)”、“ふるまい(Behaviour)”、“嫌なこと(things Faulty or hazardous)”、”世界(World)”にいつも分ける必要はありません。自分がテスト設計の時に意図することを好きなだけ入れて、整理してやればいいんです。」

「好きなだけ?」

「好きなだけ。もしお二人が、目的機能を意図してテストする方法論を次に覚えたら、目的機能というテスト観点を入れて、それ以外のテスト観点やテストコンテナとの関係を整理すればいいわけです。テストカテゴリも同様です。その上で、自分が一番使いやすいテスト観点の種類のセットを馴染みの道具としていつも携えておく、と。大事なことは、特定のテスト観点群を暗記しておけば、もしくはテスト観点の定義を暗記しておけばよいテスト設計ができるわけではなくて、自分が何を意図しているかを挙げて整理して理解することです。基本的にテスト観点は具体化していくとテストケースの構成要素になりますから、テスト観点を列挙して整理して理解できればテストケースが設計しやすくなります。」

「できるかな?」

鳥刈が始めて不安そうな顔を見せた。

「できますよ。少しずつでいいんです。最初から完璧に網羅できて完璧に整理できて完璧に理解できる人はいません。自分の実力を、テスト観点とともに育てていけばいいんです。もし手がかりが欲しければ、ラルフチャートや論理的機能構造のようなシステムを抽象化したモデルを参照するとテスト観点が挙げやすくなると思います。」

「ラルフチャート、カッコイイですよね。僕もラルフになりたいです!」

そろそろ鳥刈は限界だ。外も暗くなってきた。頃合いだな。水元は付け加えた。

「あとコツは、あまり厳密になりすぎないことです。先ほどビジネスモデルはテスト観点だと言いましたが、ビジネスモデルが直接テストケースの構成要素になるというよりは、条件やユーザといった他のテスト観点を挙げるためのヒントとして使うだけかもしれません。でももしかしたら、ビジネスモデルが直接テストケースの構成要素になる場合だってあるかもしれません。ヒントなのか構成要素なのかによってテスト観点かどうかを区別する手間をかけるくらいだったら、ふんわり両方ともテスト観点だと考えておく方が気が楽ですよ。」

「ふんわり!」

二人は顔を見合わせながら叫んだ。

「ふんわり。」

水元は微笑みながら答えた。

「ふんわり?」

二人は同じ角度で同じ大きさだけ首をかしげて、再度尋ねた。

「ふんわり。どんどんテスト設計の経験を積んで厳密に考えられるようになったら、少しずつ厳密にしていけばいいと思います。テスト観点などの概念は、よいテスト設計のための道具にすぎません。道具に振り回されて混乱するのは、もったいないですよ。」

水元はスリーブを身に纏ったグランデの紙カップを右手でゆらゆらと振って、ほらコーヒーが無くなるくらい時間が経ちましたよ、と微笑んだ。古里はそれを見て慌てて言った。

「ほら鳥刈、水元さんだって予定があるんだよ。あんまりオレたちで捕まえてちゃ申し訳ないぞ。そろそろ遠慮しないと。」

「いやでも、ここから本題に入るんだよ。テストアーキテクチャ。テストアーキテクチャの話ききたい!」

左手で鳥刈を制しながら古里は頭を下げた。

「水元さん、ありがとうございました。ちょっと僕たちでよく考えて見ます。でも、とっても面白かったです。また分からなかったら教えて頂いてもいいですか?」

どうやら認めてもらったらしいな。水元は殊勝に頭を下げる古里を見ながら、こっそり胸を撫で下ろした。よいコンサルタントの法則、第四条。コンサルタントは心配を気取られてはいけない。

「もちろんです。私もお二人と議論できて、とても楽しかったですよ。ではお肉パーティ、楽しんできてください。」

自動ドアを空けて外に出る頃にはもう侃々諤々の議論を始めているエネルギーにあふれた若い二人を後に、水元はLEDが彩る街に戻った。ちょうど待ち合わせに間に合う頃合いだ。もしかしたらこの後も、似たような議論に付き合わされながらのディナーになるかもしれない。よいコンサルタントの法則、第五条。コンサルタントはクライアントとの議論を楽しまなくてはならない。たとえそれが恋人とのディナーであったとしても。

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


「観点の蒸留」

~腕利きソフトウェアテストコンサルタントが支える優理の事件簿・アドベントカレンダー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…


境界値はテスト観点か

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