テスト設計とは、システムに対してどのようなテストを行うべきかを事前に決めることである。和田卓人は、これを主にソフトウェアテスト技法の世界で使われる用語だと説明し、ある特定のシステムや仕様がどのような検証を必要とするかを考えるテスト設計の研究は日本で特に盛んであり、QA エンジニアやテストエンジニアがこれらの技法を使って何をどうテストするかを決めていると述べている。
安井力は、テスト設計に属する技法として、同値分割、境界値分析、ドメイン分析、デシジョンテーブル、HAYST 法、ペアワイズテストを挙げている。
用法
和田の立場は、TDD の実践者もテスト設計を行っているが、その名前のもとで形式化していないだけだ、というものである。TDD はプログラマーの視点から来ているため、タイピングする前に頭の中で検討するのはアーキテクチャやデータ構造であり、次に何をテストするかを決めることはその設計の一部である。和田は QA の側にも同じ対応関係を見ている。テストエンジニアは手動テストが始まってから何をテストするかを決め始めるのではなく、どの機能群をテストするのが効果的か、どれが欠陥を見つけやすいか、検証が必要な項目を最も少ない手数でどう網羅するかを事前に考えておく。
安井は、これこそプロンプトの与え方が差を生むステップだと報告している。彼が試した範囲では、望むことを説明してモデルにテストを書くよう頼むだけでは、モデルに論理的に推論させることはできない。境界値分析を使うよう、特定のデシジョンテーブルを作るよう、あるいは同値クラスを抽出するよう指示すると、まずまずの結果が得られる。彼の言い方では、人間がテスト設計について論理的に考えるために使う道具をモデルに使わせると、モデルも論理的に考えるようになる。これをプロンプトエンジニアリングになぞらえているのは、安井ではなくインタビュアーである。
安井はさらに、モデルは人間が行ったテスト設計をレビューするのにも役立ち、モデルが行ったテスト設計をモデルにレビューさせることもありえなくはないと付け加えている。ただし、「何もわからないのでテストを考えてくれ」という形で全部を丸投げするのはうまくいかないという。
適用範囲
これは、この対話が繰り返し人間の側に戻しているステップである。生成 AI は、テストを書くことの学習コストと実装コストの両方を下げ、既存の振る舞いを捉える 仕様化テスト に強いとされるが、どのテストを追加すべきかを決めることは、人がテスト設計を通じて考える別の問題として扱われている。テストリスト についても同じ線引きがなされている。モデルはリストの形をしたものを作り出して TDD に入るハードルを下げることはできるが、リストに何を載せるべきかは設計上の判断であり続ける。