はじめに
業務システムの開発では、試験仕様書をExcelで作成している現場も多いと思います。
例えば、
| No | 試験項目 | 前提条件 | 操作 | 期待結果 |
|---|---|---|---|---|
| 1 | 正常登録 | 未登録 | 登録する | 登録される |
| 2 | 必須チェック | 名称未入力 | 登録する | エラーになる |
のようなものです。
この試験仕様書のレビューは意外と時間がかかります。
確認する内容は、
- 試験観点が漏れていないか
- 正常系だけになっていないか
- 境界値があるか
- 前提条件と期待結果が一致しているか
- 同じ試験が重複していないか
- 設計書の仕様を網羅しているか
など、多岐にわたります。
そこで、
Excelの試験仕様書をAIにレビューさせられないか
試してみました。
結論
先に結論を書くと、
一次レビューとしてはかなり使える。ただし最終レビューを任せるのは危険
という感触です。
AIが特に得意なのは、
- 記載漏れ
- ケース重複
- 表記揺れ
- 条件の矛盾
- 基本的な境界値不足
- 正常系 / 異常系の偏り
です。
逆に苦手なのは、
- 業務固有の暗黙仕様
- Excel上の複雑な見た目
- 図形やコメントに埋まった情報
- 複数機能間の仕様関係
- 「このケースは別シナリオですでに確認済み」の判断
です。
Excelをそのまま渡せば全部読めるわけではない
ここは注意が必要です。
Spreadsheet入力に対応しているAIでも、
Excelを渡した = Excel上に存在するものを完全に見ている
とは限りません。
試験仕様書に、
- 図形
- 吹き出し
- スクリーンショット
- オブジェクト
- 色だけで表現している情報
がある場合は要注意です。
必要なら、
Excel
+
PDF化した資料
+
設計書
のように渡す方法も考えられます。
まずExcelの構造を理解させる
いきなり、
レビューしてください
とは依頼しません。
まず、
このExcelは試験仕様書です。
最初にレビューは行わず、
ファイル構造を解析してください。
以下を整理してください。
- シート一覧
- 各シートの用途
- 試験ケースIDの列
- 試験項目列
- 前提条件列
- 操作列
- 期待結果列
- 備考列
列を誤認している可能性があれば、
その旨も記載してください。
とします。
ここでAIが列構成を正しく理解しているか確認します。
試験仕様書レビューの観点
レビュー時には、観点を明示します。
以下の観点でレビューしてください。
1. 正常系不足
2. 異常系不足
3. 境界値不足
4. 必須チェック不足
5. 最大桁数 / 最小桁数
6. 日付境界
7. null / 空文字
8. 重複ケース
9. 前提条件と操作の矛盾
10. 操作と期待結果の矛盾
11. 期待結果が曖昧
12. ケース単体で再現できない
これだけでも指摘精度は上がります。
設計書も一緒に渡す
試験仕様書だけを見ても、
仕様網羅性
は判断できません。
そのため、
基本設計書
詳細設計書
試験仕様書
をセットでレビューします。
プロンプトは、
設計書を正としてください。
試験仕様書について、
設計書に記載された仕様が
試験ケースとして確認されているかレビューしてください。
以下の順番で行ってください。
1. 設計書から試験観点を抽出
2. 試験仕様書のケースと対応付け
3. 対応するケースがない仕様を抽出
4. ケースはあるが期待結果が不足しているものを抽出
とします。
「設計書の記載」まで出させる
AIが、
○○の試験が不足しています
と言っても、本当に不足しているのか確認する必要があります。
そこで、
不足を指摘する場合は、
根拠となった設計書の
- 章
- 項目
- 該当記述
も記載してください。
とします。
自分なら使うプロンプト
あなたは業務システムのテスト設計レビュー担当です。
添付したExcelは試験仕様書です。
# 目的
試験ケースの漏れ・重複・矛盾を
一次レビューで検出すること。
# レビュー観点
1. 正常系
2. 異常系
3. 境界値
4. 必須チェック
5. 桁数
6. 日付
7. 重複
8. 前提条件
9. 操作
10. 期待結果
11. ケース間の矛盾
# ルール
推測だけで指摘しないでください。
設計書から判断した場合は、
根拠となる記載を示してください。
仕様上判断できない場合は
「要確認」としてください。
# 出力
|No|重要度|対象ケース|観点|指摘内容|根拠|追加ケース案|
重要度：
High
Medium
Low
最後に、
- 不足ケース候補
- 重複ケース候補
- 要確認事項
- レビューできなかった範囲
を記載してください。
色付きセルや図形は注意する
Excelの試験仕様書では、
黄色 = 今回変更箇所
灰色 = 対象外
赤色 = 要確認
のように、色そのものに意味を持たせているケースがあります。
また、
- テキストボックス
- 図形
- コメント
- スクリーンショット
に重要な仕様が書かれている場合もあります。
これらはAIへファイルを渡す方法によっては正しく取得されません。
そのため、
何をAIが読めていて、何を読めていないのか
を先に確認した方が安全です。
AIレビューと人間レビューを分ける
最終的には、こういう役割分担がよいと感じています。
AI
表記揺れ
重複
境界値
ケース漏れ候補
単純な矛盾
大量ケース比較
↓
人間
業務仕様
重要ケース
設計意図
機能間整合性
AI指摘の妥当性確認
AIで一次レビューして、
人間が考えるべきところへレビュー時間を使う
イメージです。
まとめ
Excelの試験仕様書レビューをAIに任せてみると、
特に、
- 重複ケース
- 境界値
- 記載矛盾
- 期待結果不足
- 設計書との単純な突合
は相性がよいです。
一方、
- 業務固有ルール
- 暗黙仕様
- 図形や色
- 複数機能間の関係
については、人間のレビューがまだ重要です。
個人的には、
AIに試験仕様書をレビューさせる
というより、
AIに人間が見るべき箇所を探してもらう
くらいの使い方がちょうどよいと思っています。
参考資料
-
OpenAI「File inputs」
https://developers.openai.com/api/docs/guides/file-inputs -
OpenAI「Structured Outputs」
https://developers.openai.com/api/docs/guides/structured-outputs -
OpenAI「Prompt engineering」
https://developers.openai.com/api/docs/guides/prompt-engineering