はじめに
前の記事では、Excelで作成した試験仕様書をAIにレビューさせる方法を書きました。
ただ、結合試験になると話が少し変わります。
単純に、
入力
↓
処理
↓
期待結果
を確認するだけではありません。
結合試験では、
機能A
↓
機能B
↓
承認
↓
機能C
↓
帳票
↓
外部連携
のような機能間のつながりを確認します。
さらに、
- 権限
- ステータス
- 履歴
- 更新順序
- 前処理
- 後処理
なども絡みます。
そこで、
AIに結合試験仕様書をレビューさせた場合、どこまで確認できるのか
整理してみます。
単体のケースレビューとは違う
例えば次のケースがあります。
① 申請登録
② 承認
③ 登録内容照会
それぞれ単独では正しい試験でも、
①のデータを
②で承認し
③で確認する
という流れが確認されていなければ、結合試験として不足する可能性があります。
つまり、
ケース単体ではなく、ケース間の関係を見る必要があります。
最初に機能一覧を作らせる
いきなりPCLや試験仕様書をレビューさせるのではなく、まず設計書から機能を整理させます。
添付した設計書から
今回の試験対象機能を整理してください。
以下の形式にしてください。
|機能ID|機能名|入力|出力|更新テーブル|次に関連する機能|
機能間マトリクスを作る
次に、
機能間の組み合わせ
を作らせます。
例えば、
| From / To | 登録 | 変更 | 承認 | 照会 | 取消 |
|---|---|---|---|---|---|
| 登録 | - | ○ | ○ | ○ | ○ |
| 変更 | - | - | ○ | ○ | ○ |
| 承認 | - | - | - | ○ | ○ |
この表を作るだけでも、
登録 → 承認はあるが、変更 → 承認のシナリオがない
といった漏れを発見しやすくなります。
権限も別軸で確認する
業務システムでは、
管理者
担当者
一般ユーザー
など、複数権限があります。
全権限 × 全機能を試験すると、ケース数が爆発します。
そこでAIに、
権限ごとの差分を整理してください。
同じロジックを通るものと、
権限固有の動作があるものを分けてください。
と依頼します。
これを元に、
全パターンを試験する必要があるのか
を人間が判断します。
「横展開」の意味をAIに理解させる
結合試験レビューで難しいのが、
横展開確認
です。
例えば、
権限Aで確認済みなので、
権限Bでは代表ケースだけ確認する
という設計があります。
AIはこれを知らないと、
権限Bのケースが不足しています
と大量に指摘します。
そこで、
今回の横展開方針：
- 共通ロジックは代表権限で詳細確認する
- 他権限では利用可否と登録可否を確認する
- 権限固有処理がある場合のみ詳細ケースを追加する
のように、レビュー方針そのものをAIへ渡す必要があります。
状態遷移を作らせる
結合試験では状態遷移も重要です。
例えば、
未申請
↓
申請中
↓
承認済
↓
変更申請中
↓
変更承認済
という状態があるとします。
AIには、
設計書からステータスの状態遷移を抽出してください。
以下を作成してください。
|現在状態|操作|遷移後状態|実行可能権限|
と依頼します。
その後、
各状態遷移について、
試験仕様書に対応するケースが存在するか確認してください。
とします。
これは結合試験レビューとかなり相性がよいです。
正常ルートだけでなく「途中変更」を見る
意外と漏れやすいのが、
処理途中でデータが変更された場合
です。
例えば、
申請
↓
承認待ち
↓
マスタ変更
↓
承認
のようなケースです。
登録時には存在したデータが、
承認時には、
- 無効
- 削除
- 有効期限切れ
- 別状態
になっている可能性があります。
AIには、
シナリオの開始時と終了時の間に、
参照データが変更された場合に影響する箇所を抽出してください。
と依頼します。
CRUDだけでなく副作用を見る
画面上の処理が成功するだけでは不足することがあります。
例えば、
承認
したことで、
DB更新
履歴追加
メール送信
帳票生成
外部連携対象化
が行われるとします。
この場合、
承認できた
だけではなく、
承認
├ DB
├ 履歴
├ メール
├ 帳票
└ 連携
まで確認する必要があります。
結合試験レビュー用プロンプト
あなたは業務システムの
結合試験レビュー担当です。
添付資料：
- 基本設計書
- 詳細設計書
- 結合試験仕様書
# 目的
機能単体ではなく、
機能間の連携を含めて
試験シナリオの不足を確認すること。
# レビュー観点
1. 機能間連携
2. 状態遷移
3. 権限
4. 登録→変更→削除
5. 申請→承認→取消
6. 履歴
7. 前後処理
8. メール
9. 帳票
10. バッチ
11. 外部連携
12. エラー後の状態
13. 処理途中で参照データが変更された場合
# 手順
1. 対象機能一覧を作る
2. 機能間マトリクスを作る
3. 状態遷移を作る
4. 権限差を整理する
5. 試験仕様書と対応付ける
6. 未確認パターンを抽出する
# 指摘ルール
単純に全組み合わせを
不足として指摘しないでください。
既存ケースで確認済みの場合は、
そのケースIDを提示してください。
根拠がない場合は
「要確認」としてください。
# 出力
## 共通指摘
複数ケースに共通する指摘。
## 個別指摘
|No|重要度|ケースID|観点|指摘|根拠|追加案|
## 未確認シナリオ
|From|To|権限|状態|既存ケース|判定|
## 要確認事項
設計書だけでは判断できないもの。
「既レビューケース」を渡す
AIレビューを繰り返す場合、
以前指摘した内容を毎回指摘される問題があります。
そこで、
既レビュー結果
もコンテキストに含めます。
例えば、
CASE-001についてはレビュー済み。
CASE-020〜030は
CASE-001と同じ共通処理を利用しているため、
同一観点は確認済みとして扱う。
とします。
これによりレビュー結果のノイズを減らせます。
共通指摘と個別指摘を分ける
例えば30ケースすべてで、
期待結果にDB更新内容を記載してください
という問題があった場合、
30件出されても困ります。
そこで、
同一原因による指摘は
「共通指摘」にまとめてください。
とします。
AIが特に役立つところ
結合試験レビューでAIが役立つのは、
大量の対応関係を保持すること
です。
人間が、
CASE-001
CASE-002
CASE-003
...
CASE-080
をレビューしていると、
これ、どこかで確認したっけ？
となります。
AIに、
仕様
↕
シナリオ
↕
ケースID
の対応表を作らせるだけでもレビューがかなり楽になります。
一方で、AIだけでは難しい部分
結合試験では、
このシステムでは
このパターンは業務上発生しない
という暗黙知が多くあります。
AIは設計書に書かれていなければ分かりません。
そのため、
理論上可能
と、
業務上必要
を区別する必要があります。
ここは人間の判断が重要です。
おすすめの役割分担
AI
│
├ 機能一覧作成
├ 機能間マトリクス
├ 状態遷移
├ ケース紐付け
├ 重複検出
├ 漏れ候補
└ 横展開候補
↓
人間
│
├ 業務上必要か判断
├ リスク判断
├ 試験範囲決定
└ 最終レビュー
AIをレビュアーそのものにするのではなく、
レビュアーの補助者として使う
イメージです。
まとめ
AIに結合試験仕様書をレビューさせてみると、
- 機能間マトリクス
- 状態遷移
- 権限差
- シナリオ間の関係
- 既存ケースとの重複
- 仕様とケースの対応付け
で力を発揮します。
一方、
- 業務上あり得るか
- どこまで試験すべきか
- リスクを許容できるか
- 横展開で十分なのか
といった判断は、人間が行う必要があります。
結合試験レビューを完全自動化するというより、
数十〜数百ケースを頭の中で紐付ける作業をAIに手伝ってもらう
という使い方が、現状ではかなり実用的だと感じています。
そして一番重要なのは、
AIに試験ケースを見せるだけではなく、設計書・レビュー方針・既レビュー結果までコンテキストとして渡すこと
です。
参考資料
-
OpenAI「How OpenAI uses Codex」
https://openai.com/business/guides-and-resources/how-openai-uses-codex/ -
OpenAI「Prompt engineering」
https://developers.openai.com/api/docs/guides/prompt-engineering -
OpenAI「File inputs」
https://developers.openai.com/api/docs/guides/file-inputs