第12章テスト工程 ── 観点カバレッジとDDPモニタリング
この章が扱うこと
本書が扱うのは要件定義と外部設計なので、この章が対象にするのは、それぞれに対応する総合テストと結合テストです。単体テストは、実装の側の話です。
この章が示すのは考え方までで、運用の手順（マトリクスの作り方、DDPの集計の実務、帳票の様式、合否の閾値）には踏み込みません。テストの運用は、契約の形・体制・道具・発注者の検収の求めによって、プロジェクトごとに大きく違うからです。
テストの網羅を、どう示すか
テストの段になると、網羅をどう示すかを問われます。
テストの網羅は、試験観点 × 試験シナリオのマトリクスで示す。
行に観点（何を確かめるべきか）、列にシナリオ（どういう筋書きで動かすか）を置き、そのシナリオでその観点を確かめるなら、交点に印を付けます。送料無料の閾値の例なら、総合テストでは次のようになります。
| 試験観点 ＼ 試験シナリオ | S1 通常の受注 | S2 キャンペーン中の受注 | S3 受注の途中でキャンペーンが終わる | S4 閾値を切り替えた担当者が異動した後 |
|---|---|---|---|---|
| 送料の計算（閾値のちょうど上と下） | ○ | ○ | ○ | |
| 閾値の切り替え（切り替えてよい役割か） | ○ | ○ | ||
| 変更履歴の記録（誰が・いつ・何から何へ） | ○ | ○ | ||
| キャンペーン期間の切り替わり | ○ |
すべての交点を○で埋める必要はありません。そのシナリオで確かめなくてよい観点もあるからです。見るのは、観点ごとに、確かめるべきシナリオで確かめられているかです。その判断は、人がしっかり行います。
マトリクスが示せるのは、並べた観点とシナリオの中での網羅だけです。観点やシナリオそのものが抜けていれば、表はきれいに埋まっていても、その抜けは表からは見つかりません。だから、試験観点と試験シナリオは、人がしっかり考えます。
試験観点と試験シナリオを考えるのは人である。AIに任せるのは、マトリクスの整備・突き合わせ・印のない交点の指摘といった作業の支援に限る。
この業務で何を確かめないと困るのか（送料無料なら、閾値のちょうど境目の受注や、キャンペーンが切り替わる瞬間の受注）を挙げるには、業務の意図を知っている人の知識が欠かせません。
試験シナリオの種は、要件定義で整理した業務イベントと例外、そして【広げる】で歩かせたシナリオの2つです。表の S3・S4 は、【広げる】のシナリオから採ったものです。シミュレーションのシナリオはテストで使える形に近いものですが、どれを試験シナリオとして採るかは、人が決めます。
一方、次の節で見る試験手順は、AIに大いに任せて構いません。観点とシナリオは人が考える比重を重く、手順はAIに頼る、という分け方です。
AIに試験手順を書かせる
試験手順の作成は、AIに担わせます。もとになるのは、要件定義や外部設計の成果物です。タスクごとに、始めてよい状態と終わったときに成り立っている状態が書かれ、例外が整理されていれば、そこから手順が素直に導けます。
これには、副次的な効き目もあります。AIが手順を書きあぐねる箇所は、仕様に穴がある箇所です。「確認する」「正しく表示される」としか書けないなら、事後条件が決まっていません。もっともらしいが確かめようのない手順が出てきたときも、同じです。【広げる】の検証可能性のレンズで上流で見たことが、ここで答え合わせされます。
AIが試験手順を書けたことは、シグナルであって保証ではない。重みを揃えずに読む——書けないことは強い兆候、書けたことは弱い証拠である。
手順が書けたことは、仕様が確かめられる形をしていたことを示すだけで、その仕様が業務として正しいかどうかは示しません。
品質を、何で追うか——DDP
テストの品質は、DDP（Defect Detection Percentage：欠陥検出率）で追います。DDPは、ある工程で見つけるべきバグを、その工程でどれだけ見つけられたかの割合です。
たとえば、結合テストで40件のバグを見つけ、そのあと総合テスト以降で、結合テストで見つけるべきだったバグが10件見つかったとします。結合テストは、見つけるべき50件のうち40件を見つけたので、DDPは80%です。工程ごとに、この値の推移を追います。
DDPを使う狙いは、バグ密度・テスト密度のような、コードの規模で割る指標から降りることにあります。AIがコードを書く時代に、コード行数あたりのバグ件数やテスト件数で品質を語るのは無理があります。同じ機能が半分の行数で書かれれば密度は倍になりますが、品質は何も変わっていません。
AI-Native開発では、DDPを読み違えやすい
AI-Native開発では、テストに持ち込まれるバグの数そのものが減ります。AIにコードを書かせると、書き間違いや書き漏らしのような単純なバグが少なくなるからです。上流の仕様を育てていれば、仕様の穴から来るバグも減ります。そのぶん、DDPには次の2つの読み違えが起きやすくなります。
①バグが減ると、DDPは見かけ上、悪くなります。難しいバグほど見つけにくく、すり抜けやすい。単純なバグが先に消えると、テストに残るのは難しいバグの割合が高くなり、各工程で見つけられる割合が下がるからです。
| 結合テストで見つけた | 後の工程へすり抜けた | 結合テストのDDP | |
|---|---|---|---|
| 案件A（人がコーディングした） | 90件 | 10件 | 90% |
| 案件B（上流を育て、AIに実装させた） | 20件 | 5件 | 80% |
案件Bは、バグの総数も（25件と100件）、すり抜けた数も（5件と10件）、案件Aより少ないのに、DDPだけを見ると案件Aより悪く見えます。数字を機械的に読むと、AI-Native開発に切り替えたプロジェクトほど「品質が下がった」と誤読されます。
②バグが少ないほど、1件で大きく振れます。DDPは割合なので、母数が小さいほど不安定です。見つけるべきバグが100件ある工程では、1件の見逃しは1ポイントしか動きませんが、10件しかない工程では10ポイント動きます。バグが減るほど母数は小さくなるので、この不安定さは避けられません。この手法を提案した側の適用事例でも、バグが少ない案件では参考程度の活用にとどめたと報告されています。
①と②は、同じ方向を向いています。バグが減るほど、DDPは読みにくくなります。
DDPを、単独で合否を語る指標にしない。定量の数値だけで判断せず、定性の判断を併せる。
何がすり抜けたのか、なぜ捕まえられなかったのか、それは工程の設計の問題か観点の問題かを、1件ずつ見ます。DDPは傾向を読むための物差しで、閾値で合否を出すための装置ではありません。