AIに作らせたテストケースは、なぜ必要かが消える

GPT-4.5にテスト観点の生成を頼んだら、想定より少ない数のテストケースしか出てこなかった。MIXIの松谷峰生氏が公開した資料「AI時代のテストの基礎を再定義する」に出てくる「テスト項目5件事件」だ(出典)。

数が足りない、で終わる話ではないらしい。資料が本当に問題にしているのは、テストケースの数の過不足ではなく、それぞれのケースがなぜ必要かを、あとから誰も追えなくなる構造の方だ。

AIが単独でテストケースを作ると何が消えるか

資料の指摘はこうだ。AIに丸ごとテストケースを作らせると、「そのテストケースはなぜ必要か」と「何が抜けているか」を追えなくなる。生成された時点では、それらしいテストケースの一覧が手元に残る。だが半年後、誰かがそのテストケースを見直そうとしたとき、なぜこの項目がここにあるのかを説明できる人はいない。

松谷氏が示す対処は、生成を一段階で済ませないことだ。リスク特定、テストアプローチ決定、テスト観点抽出、テスト設計、テストケース作成という五段階に分け、各段階の成果物にIDを振って連鎖させる。あるテストケースを起点に、それがどのテスト観点から来て、どのアプローチに基づき、最終的にどのリスクに対応しているかを遡れるようにする。

一段階で生成されたテストケースの一覧と、五段階のIDで連鎖したテストケースの一覧は、見た目はどちらも同じ表になる。違うのは、後から「なぜこれが必要か」を再構成できるかどうかだけだ。

PRレビューでも同じことが起きている

これは、PRレビューで起きている問題と同じ構造をしている。AIにコードを生成させると、それらしく動くコードの差分が手元に残る。だが、なぜその実装を選んだのか、どのリスクを想定していたのかは、コードそのものからは読み取れない。差分は結果であって、そこに至った判断の連鎖ではない。

PRレビューツールParryが、PR作成時にWhy(なぜこの変更か)、Risk(影響範囲)、Confidence(自信度)、Context(背景)という4項目の入力を必須にしているのは、松谷氏のID連鎖と同じ発想である。テストケースが「どのリスクに対応しているか」を後から辿れるようにするのと、PRが「なぜその変更を選んだか」を後から辿れるようにするのは、同じ問題を別の工程で解いている。

テストとコードレビューは、扱う対象がまったく違う。だが、AIが一段階で生成した成果物には、判断の連鎖が残らないという弱点は共通している。

変わらないもの、変わる手段

資料は最後にこう書いている。「我々が実現したいことは何も変わっていない。変わるのは実現手段である」。手動でテストを設計していた時代も、AIにテストケースを作らせる時代も、目指す先はユーザー満足という一点で変わらない。変わったのは、そこに至る手段だけだ。

同じことが、コードレビューにも言えるはずだ。人間が一行ずつレビューしていた時代も、AIがコードを生成する時代も、レビューが確かめたいことは変わっていない。なぜこの変更が必要で、何を捨てて、どこにリスクがあるか。手段がAIによる生成に変わったからといって、確かめたいことまで変わるわけではない。

変わらないのは目的で、変わったのは、判断の連鎖がAIの出力の裏側に隠れやすくなったことだ。松谷氏がテストにIDの連鎖を持ち込んだのも、Parryが四軸をPRに持ち込んだのも、隠れやすくなった連鎖を、もう一度手元に引き戻す作業なのだと思う。