テストチャーターとは？ AI時代に「人とAIの共通言語」へ広がる役割

JSTQBが発行しているテスト技術者資格制度 Foundation Levelシラバス Version 2023V4.0.J02では、

探索的テストは、テスト担当者がテスト対象について学習しながら、テストケースを同時に設計、実行、評価する。探索的テストは、テスト対象についてより深く知り、注力したテストでより深く探索し、まだテストしていない領域のテストを作成するために使う。

とされています。

この探索的テストは、テスト技法の中でも経験ベースのテスト技法に分類され、テスト担当の知識や経験、スキルに依存するテスト技法とされています。

あわせて読みたい：探索的テストとは？目的や観点、やり方、モンキーテストとの違いなど解説 

テストチャーターとは、探索的テスト技法で用いるテストウェア※の一つであり、テストセッションの目的や方向性を簡潔に示す文書です。ISTQB用語集では、「テストセッションのゴールや目的を記述したドキュメント」と定義されています。

※ソフトウェアテストの計画、設計、実行の過程で作成される成果物やツールの総称

一般には、次のような内容を記載します。

• 何をテストするか
• 何を明らかにしたいか
• どのリスクや観点を重視するか
• どの環境、データ、時間で実施するか
• 何を記録し、どこまで確認したら終了するか

テストケースが入力値、操作手順、期待結果を事前に具体化するものであるのに対し、テストチャーターが定めるのは「今回の探索で達成したいミッション」です。実際の操作を固定し過ぎず、テスト担当が得られた情報を基に次の確認内容を変えられる点に特徴があります。

例えば、ログイン機能を対象にするなら、次のように表現できます。

異常入力、権限差、セッション切れを中心に、正規ユーザーが利用できなくなる問題や、不正アクセスにつながる問題を探索する。 

これは、思い付くままに操作するアドホックテストとは異なります。テストチャーターは探索の自由度を確保しながらも、目的、重点リスク、制約、記録を明らかにすることで、テストを説明可能な活動とするために文書化するものです（図表1）。 

なお、本稿で述べるテストチャーターの「役割の拡張」は、ISTQBなどの正式な定義が変更されたという意味ではありません。AIを活用することを前提として、実務上の使い方を広げて捉えるものです。

図表1：テストケースとテストチャーターの比較

探索的テストは、テスト担当が持つテスト対象に対する知見や操作や運用などのノウハウを用いて、テストの設計と実行を並行して進めます。テストチャーターは、自由な探索が場当たり的な操作にならないよう、テスト担当の注意を重要な領域へ向ける羅針盤として使われています。

探索的テストによるテスト実行を通して、一定時間のセッションを設定し、実施した操作、発見事項、不具合、未確認領域などを記録します。これにより、テストチームでは「テストで何を狙い、どこまで調べ、何が分かったのか」を共有できます。

従来の主な読み手は人のテスト担当であり、適用範囲も一つの探索セッションが中心でした。AIがテスト活動に参加するようになることで、チャーターの読み手と使われる場面が広がります。

生成AIの普及により、テストチャーターの位置付けが変わりつつあります。そこで、AI時代に求められる新たな役割を説明していきます。

AIが増やすのは「候補」。テストの目的までは決めてくれない

生成AIは、テスト観点、テストケース、テストデータ、自動化コードの候補を短時間でテストベースの仕様書から作れます。また、テスト実行時の実行ログの要約や、不具合候補の分類にも生成AIを活用できます。

一方、生成AIによる出力の量とテストの有効性は常に同じとは限りません。

テスト条件として本来押さえておきたい業務上の損失が大きい箇所、顧客が重視する品質、過去障害の傾向、法令や契約上の制約は、十分な背景情報をプロンプトとして与えなければ出力に反映されません。

このため、不十分な入力から、文脈のみを推察して生成されたテストケースの期待結果が、実際の仕様と食い違うこともあり得ます。

例えば、テスト対象がチケット予約システムだとします。AIへ単に「この機能のテストケースを作ってください」と依頼した場合、一般的な正常系や異常系なら多数生成されるでしょう。しかし、予約サービスで本当に重大なのが、残り1席へ同時に申し込みが入った際の二重予約防止を確認することだとしても、その業務リスクを伝えなければ、AIが重点的にテストケースを生成するとは限りません。

このため、AIへ次のような情報を渡すようにすることで、適切なテストケース生成へつなげられるようにします。

• テスト対象と達成したい目的
• 重点的に確認する品質リスク
• 参照すべき仕様、受け入れ基準、過去障害
• 正誤を判断する基準
• 実施してはいけない操作
• 人の確認や承認が必要な箇所

これは、従来のテストチャーターをAI活用へ拡張した姿と言えます。AIが速く動けるからこそ、方向を誤った場合には、短時間で大量の不要な成果物を生み出してしまうかもしれません。

だからこそ、重要なのは「どう生成させるか」より先に、「何のために生成させるか」を定めておくことです（図表2）。

テストチャーターは「人とAIの共通言語」になる

従来のテストチャーターが人の探索を導く文書だったとすれば、これからは、人とAIが品質上の意図を共有する文書へ役割を広げるものと筆者は考えています。

ここで大切なのは、テストチャーターを単なる長いプロンプトにしないことです。プロンプトは、利用するAIツールや作業ごとに変わります。しかし、テストを通して評価・確認すべきユーザー価値や品質目標は、ツールが変わっても維持されるべきものです。

テストチャーターには、まず判断に必要な文脈を持たせます。ユーザー、業務目的、関連機能、過去障害、品質上の優先順位などです。次に、AIが利用しても問題ないデータや実行してよい操作を定めます。削除、決済、外部送信など、影響の大きい操作には人の承認を求めるといった境界線が必要です。

そして、何をもって正しいと判断するのか、どの発見を重大とみなすのか、どの証跡を残すのかを共有します。AIから何かを出力させること自体がゴールではありません。その出力を評価できて、初めてテスト活動に利用できるのです。

かつてテストチャーターは、主にテスト担当が使う文書でした。これからはAIも読み、人も読む。同じ品質目標へ向かうための共通言語になる、というのが筆者の中心的な考えです。

具体的にテストチャーターの記述がイメージしやすくなるように、以下にWebアプリケーションのログイン機能と決済機能を例にした記述例を図表3と図表4に示します。ご参考としてください。

ログイン機能の例

図表3：ログイン機能のテストチャーター

決済機能の例

図表4：決済機能のテストチャーター

テストチャーターは、AIを使う一つの作業だけでなく、テスト活動全体の起点として利用できます。

テスト分析では、仕様書、ユーザーストーリー、過去障害をAIに参照させ、テストチャーターの目的に沿ってリスクや不足観点を提案するようプロンプトを作成します。これに対して、人は業務影響と優先順位を踏まえて、その提案を採用するかどうかを判断します。

テスト設計では、採用した提案内容を基に、同値クラス、境界値、状態遷移、異常な組み合わせなどへ展開させます。このとき、テスト実行による期待結果だけでなく、その根拠となる仕様や受け入れ基準も示させると、レビューしやすくなります。

テスト実行中には、画面、応答、ログを基に、次に確認すべき操作や未確認領域をAIに提案させることもできます。テスト結果分析では、実行記録の要約、類似事象の整理、テストチャーターに対する実施状況の可視化を支援させることもできます。

ただし、不具合かどうか、重大度をどう設定するか、リリースしてよいかという最終判断は、人が責任を持って行います（図表5）。

従来の「対象、目的、観点、時間」に加え、AIを利用する場合には、少なくとも次の内容を明確にしなければなりません。

• 守りたいユーザー価値と重点リスク
• 参照する仕様、受け入れ基準、障害履歴とその版
• AIに任せる作業
• 人が責任を持つ判断
• 自動実行できる範囲と、人の承認が必要な操作
• 個人情報、機密情報、本番データの取り扱い
• AI出力を誰が、何を基準にレビューするか
• 入力、出力、採否理由、操作ログなどの証跡
• 終了条件と残課題の扱い

例えば、電子取引における決済機能なら次のようにテストチャーターを記述できます。

目的：キャンセルと返金処理を対象に、二重返金、金額不整合、注文・決済・会計の状態不一致を探索により確認する。
重点リスク：通信断、タイムアウト、ボタン連打、外部決済の応答遅延、ユーザー権限差。
AIに任せること：状態遷移と異常系候補の生成、ログ差分の整理、未確認領域の提案。
AIに任せないこと：本番データの利用、実際の返金処理、合否や重大度の最終判断。
判断基準：注文・決済・会計の状態と金額が一致し、処理の重複がないこと。
終了条件：90分で重点リスクを一巡し、未確認領域とAI提案の採否理由を記録する。

このような形式で表現すれば、同じテストチャーターを人による探索、AIによる観点生成、結果分析のいずれにも利用できます。

ここまで説明した通り、人がプロンプトを通して適切な指示をを出せるなら、AI時代のテストチャーターは便利なテストウェアになります。

一方で、運用時に注意すべき点もあります。活用する際に押さえておきたいポイントを以下にまとめます。

AIの出力をうのみにしない

テストチャーターを用意しても、AIの出力が自動的に正しくなるわけではありません。生成された期待結果や仕様解釈は、必ず参照元と照合する必要があります。使用したモデルや設定、参照した仕様の版、入力した情報も記録しておくと、後から検証しやすくなります。

機密情報・個人情報の扱い

個人情報、認証情報、ソースコード、障害ログなどをAIへ入力する場合は、個人情報や機密に対する組織のルールを確認し、必要に応じて匿名化、マスキング、アクセス制御などを行います。

情報を詰め込み過ぎない

チャーターへ情報を詰め込み過ぎないことも大切です。本文にはミッション、重点リスク、制約、判断基準を簡潔に示し、詳細な仕様や障害履歴は参照先として管理する方が実用的です。

テストケースや自動テストとの使い分け

テストチャーターは、正式なテスト計画、受け入れ基準、再実行可能なテストケース、自動テストを置き換えるものではありません。

既知の振る舞いはテストケースへ落とし込み、繰り返し確認する内容は自動化する。不確実性や変化の大きい領域は、テストチャーターを使って探索する。こういった使い分けは、AIがテストケースの作成に加わっても変わりません。

テストチャーターは、探索的テストの方向を定める方針書として使われてきました。AI時代には、その役割が「人への探索指示」から、「人とAIが共有する品質上の目的、制約、評価基準」へ広がっていきます。

AIが大量のテストケースを生成できる時代に、価値を生むのは件数の多さではありません。どのリスクに向き合い、何を守り、どの根拠で判断するかが明確であることです。

AIは、正しい方向にも、誤った方向にも、テスト活動を導く可能性があります。だからこそ、その方向を定めるテストチャーターは重要になっていくことでしょう。

AIに指示を与えるためのプロンプトの書き方のお作法は変わっていきますし、AIツール自体も進化していきます。だからといって、テスト対象における品質目標は変わることはありません。

テストチャーターは、その品質目標を人とAIの間で受け渡すための、実践的な共通言語として、ますます有益なテストウェアとしての利用が広まっていくことでしょう。

あわせて読みたい：モンキーテストとは。ランダムテスト・アドホックテストとの違い、実行方法など解説