真ん中が一番難しい？―AIとテスト設計

この言葉が指す範囲は、人によって大きく異なります。テストケースを書く作業だけを指す人もいれば、そもそも何を確かめるべきかを決める上流まで含める人もいます。この記事では広く捉え、大きく三つの層で考えます。入口で「このシステムの何を、どこまで確かめるか」を決める。真ん中で、仕様を把握してテスト設計書に仕上げる。出口で、「その設計書が品質を保証するに足るか」を確かめる。この三つの大きな段階を経て、テスト設計というタスクは完了する、と定義することにします。

この三層を、もっと細かく分解すると、次の七つの工程になります。

1.何を対象に、どこまで、どれぐらいの細かさでテストするかを決める
2.仕様書を読み解き、仕様を把握する
3.テスト観点を洗い出す
4.テスト結果に影響を与える条件の組み合わせを探索する
5.テストの実行手順と期待値を書く
6.テストケースとして、テスト設計書に仕上げる
7.そのテスト設計書が、テストしたいことに対して必要十分かをレビューする

先ほどの三層に紐づけると、入口の「決める」（①）、真ん中の「把握して、設計書に仕上げる」（②〜⑥）、出口の「確かめる」（⑦）、となります。手間の大半は真ん中に集まっています。

だから、テスト設計と聞くと多くの人は、まず真ん中を思い浮かべます。仕様書を読み込み、複雑な条件・依存関係を把握し、観点を洗い出し、その観点をテストするために必要な実行手順を考え、期待値を設定し、テストケースを一つずつ書き起こすという、手間暇のかかる長い作業です。私たちも、テスト設計をAIで高速化しようと考え始めたころは、そう見ていました。一番苦労するところなので、そこをAIに手伝ってもらえれば、最も効率化できるはずだ、と考えていました。

ところが、取り組んでみると、逆でした。その重い真ん中を、AIはむしろ楽にこなします。すると、本当に難しいのはどこなのか、という問いが残ります。

私たちがいまAIで高速化できているのは、この真ん中、②の仕様把握から⑥の仕上げまでです。

真ん中がAI向きかどうかは、真ん中で行われている仕事の性質に左右されます。ここでやっているのは、突き詰めれば、与えられた入力を決まった形へ変換する作業です。入力は仕様書、枠は決めたスコープ。その中でAIが観点を立て、組合せを設計し、手順と期待値を埋めて、設計書にまとめます。入力があり、出力の型が決まっています。この形を、いまの生成AIはよくこなします。

仕様も、文章だけとはかぎりません。表や、画面のスクリーンショット、PDFに埋め込まれた図もあります。ばらばらの形で渡された材料を読み取って、ひとつの土台に整える。この読み取りと下ごしらえも、現在の生成AIは極めて効率的に処理できます。

いわゆる「多次元空間内の探索」もAIの得意なところです。例えば、あなたがネット通販で買い物をするときの、多種多様な商品を絞り込む画面を思い浮かべてみてください。カテゴリ、価格帯、ブランド、色、サイズ、送料無料かどうか、レビューの星の数など、指定できる条件がいくつも並んでいます。一つ一つの項目で選ぶことのできる選択肢はせいぜい三つか四つでも、その全てを掛け合わせると組み合わせはあっという間に何百、何千通りにも膨れ上がります。全部は試しきれないので、要点を押さえた最小限の組み合わせを選ぶ必要があります。この選び方には決まった型がある一方で、数が増えるほど人が行うには大きな労力を要します。AIは、ここを取りこぼしなくこなします。

真ん中でAIがしくじるときは、たいてい形式の誤りです。書式が崩れる、番号が飛ぶ、同じ確認項目の書き方が食い違う。この種のずれは、機械的なチェックで見つけて直せます。だから、真ん中はAIに任せても、あとから守りやすい。厄介なのは、形を整えても消えない誤り、つまり判断の誤りのほうです。それは、両端にあります。

真ん中が速く、安くなるほど、時間のかかる場所も移ります。大量に作成すること自体は、もはや大きな負担ではありません。代わりに重くなるのは、出てきたものを確かめるほうです。

真ん中をAIが引き受けるなら、残るのは両側です。入口の「決める」と、出口の「確かめる」、つまり、何をどこまで確かめるかを決めることも、出てきたものが必要十分であると判断することも、高品質なテスト設計を行うためには欠かせません。真ん中の作業が人間の手から離れると、より一層、その両側の判断の価値が大きくなります。

入口の「決める」は、一見一番AIに向きそうに見えます。何をテストするかは仕様書に書いてあるとおりにやればいい、と思えるからです。そう思いたくもなります。でも、仕様書をいくら読み込んでも、決まらないことがあります。

仕様書が教えるのは、システムが何をするか、です。何を守るべきか、ではありません。同じ仕様書でも、お金を扱う画面と、ヘルプの説明ページとでは、かけるべき厚みがまるで違います。どちらをどれだけ確かめるかは、壊れたときの重さを見比べて決めることです。ここが壊れたら事業にいくら損害が出るのか。今回のリリースで、どこまでのリスクなら飲めるのか。限られた時間で、どこを厚く見て、どこを薄くするのか。この線引きのよりどころは、仕様書に書かれていません。リスクの大きさも、事業の事情も、締め切りの厳しさも、AIに渡す資料の外にあります。渡す材料がなければ、AIは決められません。

私たちのやり方でも、ここはAIに任せていません。最初に、どの範囲をテストしたいのか、どの部分を厚くテストしたいのかなどを人間がまずしっかりと言語化・明文化しています。ここを決めて初めてAIが作業に着手できるわけですが、作業開始後も、仕様から決められないことに出くわすと、AIはそれらしい値で埋めず、空欄のまま残します。そして、決めるべき点をまとめて、人に一度だけ尋ねます。AIが下書きの案を添え、人はそれでよければ承認し、違えば正しい答えを与えます。こうすると、空欄は失敗ではなく、人が決めるべき場所の目印となります。守る範囲そのものが定まらないときは、AIを先へ進ませません。手を動かす前に一度止まって、そこを人に確かめさせます。土台が決まらないまま真ん中を作っても、あとで作り直しになるだけだからです。

やっかいなのは、AIが自信をもって埋めてしまう前提です。仕様からは一つに決まらないのに、たくさんの期待値を左右してしまう思い込み。これは空欄よりも見つけにくい。だからこそ、そういう前提は、こっそり埋め込まずに、人が確認できる形で表に出しておく必要があります。

「決める」には、もう半分あります。仕様書が書いていないことを疑う仕事です。良いテスト設計は、書いてあることを確かめるだけでは足りません。書き手が書き忘れた前提、想定しなかった操作、だれも触れなかった異常時のふるまい。怖い不具合は、たいていその書かれていない場所に潜みます。たとえば仕様に最大値だけが書いてあるとき、本当に危ないのは、その一つ外側だったり、書かれていない最小値のほうだったりします。ところがAIは、渡された文章とつじつまが合うように答えます。書いてあることには強く、書いていないことには弱いのです。

だから入口は、人が枠を決める仕事です。何を、どこまで、どの優先度で守るのか。枠が決まれば、内側を具体的な網羅で埋めるのは、真ん中のAIの役目になります。

一方、出口は入口と向きが反対です。入口がこれから何を作るかを決める判断なら、出口はその出来上がったものを信じてよいかを判断することです。

そもそも、テスト設計の成果物とは何でしょうか。テストケースの一覧表だ、と答えたくなります。でも、本質的な成果物はその一覧表ではありません。「この一覧で、このシステムの品質を保証してよい。過不足もない」と言い切れるだけの、裏づけのほうです。二つの異なるテスト設計書があり、そのケースの数が同じでも、守るべきところを本当に押さえられているかは全く分かりません。テスト設計書の品質を支える「これで必要十分だ」という判断が、本質的な価値です。

その判断には、引き受ける人がいります。「確認しました、保証します」と言うことは、だれかへの約束です。約束には、それを負える主体がいなければなりません。AIは、その当事者になれません。どれだけ整った設計書を書いても、保証を引き受ける一点だけは、人に残ります。

この出口を飛ばすと、どうなるでしょうか。AIが仕上げた設計書は、たいてい整っていて、抜けもなさそうに見えます。これでいい、と言いたくなります。でも、真ん中のAIは書いていないことに弱いのでした。一見抜け漏れがなさそうに見えても、仕様書に書かれていない大切なことが抜けているかもしれません。そんなテスト設計書がそのまま世に出ると、届くのは網羅ではなく、もっともらしい安心です。何も保証しないより、かえって危ういこともあります。

だから、確かめる工程では、整って見えることと、正しいことを取り違えないようにしています。抜けがなく、書式もそろい、数も合っている。それでも、見た目や形式が整っているだけで、中身が正しい証明にはなりません。たとえば、AIがあるテストケースの根拠として仕様書のある章を挙げているとします。体裁は申し分ありません。でも、その章を実際に開くと、もっと複雑な要件が記載されている、ということが起きているかもしれません。もっともらしい根拠ほど、人が現物に当たって照らさないと見抜けません。中身の正しさは、仕様書という元の資料に人が立ち返り、一つずつ照らし合わせて確かめるしかありません。レビューが担うのは、問題を挙げて判定するところまでです。直すか、これで保証してよいかを最後に決めるのは、人です。

やっかいなのは、テスト設計には、厳密な正解である「教師」が存在しないことです。プログラムなら、動かして結果を見れば、正しいかどうかが分かります。テスト設計は、動かして「これで十分か」を確かめる、というわけにいきません。十分かどうかは、守りたいものと、許せるリスクによって変わるからです。単純な数字ひとつで測れるものでもありません。だから最後は、人が、この設計で保証してよいと判断するしかありません。

こうして、テストケースの作成にかかる手間がゼロに漸近するほど、人の値打ちが上がる領域も移ります。たくさん書けることから、書かれたものを保証してよいか見極められることへ。多ければよい、というものでもありません。ケースを増やしすぎると、実行にも確認にも時間がかかり、本当に大事なケースが埋もれます。だから、増やす判断と同じくらい、削る判断が要ります。何を今回は捨てるかを、リスクを見て決める。数を並べるのは機械の仕事になり、判断が人の仕事として重くなります。

こうして見ると、難しさは真ん中ではなく、両端に移っていました。

テスト設計は、三つの層に分かれます。入口で人が決め、真ん中でAIが作業し、出口で人がもう一度、保証に足るかを見て引き受ける。判断と判断のあいだの作業を、AIが高速に担います。これが、いまのところ現実的な形だと考えています。

根っこにある理屈は、ひとつです。AIが担えるのは、与えられた材料から結果を導くことです。人が担うのは、材料が資料の外にあること（入口）と、責任そのものを生み出すこと（出口）です。真ん中は作業なのでAIに向き、両端はその作業に収まらないので人に残ります。この線引きは、AIの性能が向上しても本質的には変わらないでしょう。AIの性能・アーキテクチャ・演算速度の向上などは真ん中をもっと速くしますが、資料の外にある材料を作り出したり、人の代わりに責任を負ったりはしないからです。

これは、AIが人に取って代わる話でも、人がAIに逆らう話でもありません。速さと責任は、別のものです。速くできることと、任せてよいことは、同じではありません。真ん中はAIに速く担ってもらい、空いた時間と注意を両端の判断に向ける。品質の行方を左右するのは、その両端だからです。「AIは優秀だから」といって全てをAIに委ねて、形だけの全自動を達成しても意味がありません。その工程のどこかに、必ず人間が介入すべきポイントがあります。私たちが手掛ける「ネムラナイ」も、テスト設計・実行をAIに速く担わせつつ、入口と出口を人が受け持つ前提で構築しています。

AIは、テスト設計書を速く書き上げます。その一方で、生成されたテスト設計書を品質の保証として最後に引き受けるのは、これからも人です。