あなた
テスト仕様書を作成するにあたり網羅性を高めることが重要だと学んだ。作成するときに意識するポイントは？
ChatGPT:
テスト仕様書の網羅性を高めるためのポイント
テスト仕様書の網羅性を高めることは、ソフトウェアの品質向上に直結します。特に、仕様の抜け漏れを防ぐために、以下の点を意識して作成することが重要です。
1. 正常系・異常系・臨界値の網羅
- 正常系（Expected Cases）
期待される動作をすべて確認するため、入力パターンごとの出力を明確にする。 - 異常系（Unexpected Cases）
無効な入力やエラー処理が正しく動作するかを確認する。例えば、未入力・不正値（範囲外・型違いなど）・桁数超過など。 - 臨界値（Boundary Cases）
入力値が閾値の境界付近でどのように動作するかをテストする。特に、数値の上限・下限、ゼロ、負の値などを考慮する。
2. 入力項目の明確化
- 各テストケースにおいて、どの入力項目がどの値を取るかを明確に記述する。
- 複数の入力項目（例：管理番号、製品番号）がある場合、それぞれの組み合わせを考慮したテストケースを作成する。
3. 判断条件の考慮
- 条件分岐を網羅するテストケースを作成する。例えば、年代によって処理が異なる場合：
- 「2006年以前」「2006年ちょうど」「2006年以降」のように分岐を明確にテストする。
- ソースコードのロジックを確認し、「if-else」などの分岐条件に対応するテストケースを用意する。
4. ソースコードとの整合性の確保
- テスト仕様書とソースコードの内容が一致しているかを確認する。
- ソースコード内にある処理（特に、異常値チェックや例外処理）が、すべてテスト仕様書に反映されているかを検証する。
5. 入力値の組み合わせを考慮
- 入力項目が複数ある場合（例：管理番号、製品番号）、各項目のすべての組み合わせを考慮する。
- 例：製品番号が "A", "B", "T", "C" のように複数ある場合、各製品番号ごとの正常系・異常系・臨界値をカバーするテストケースを作成する。
6. AIの活用と人間の判断
- AIツール（ChatGPT, Geminiなど）を活用して、テスト仕様書の抜け漏れや矛盾を検出する。
- ただし、AIの提案を鵜呑みにせず、最終的にはエンジニアの判断で仕様を精査することが重要。
あなた
網羅性を高めるためにどうしたら良いか、もう少し詳しく教えてほしい。
ChatGPT:
1.正常系・異常系・臨界値を網羅する
テスト仕様書を作成する際、正常系（Expected Cases）・異常系（Unexpected Cases）・臨界値（Boundary Cases） を意識することで、より抜け漏れのないテストが可能になります。
ここでは、「製品登録システム」を例にとり、「管理番号」と「製品番号」 の入力項目があるケースを想定して、それぞれの網羅方法を詳しく説明します。
1. 正常系（Expected Cases）
正常な入力値を用いて、期待通りの結果が得られるかを確認する。
| No | テスト項目 | 入力値 | 期待される結果 |
|---|---|---|---|
| 1 | 正常登録（最小値） | 管理番号: 1000, 製品番号: A | 正常に登録される |
| 2 | 正常登録（最大値） | 管理番号: 9999, 製品番号: B | 正常に登録される |
| 3 | 正常登録（中間値） | 管理番号: 5000, 製品番号: C | 正常に登録される |
| 4 | 正常登録（特殊文字なし） | 管理番号: 2500, 製品番号: T | 正常に登録される |
| 5 | 2006年以降の正常値 | 年: 2007, 製品番号: A | 正常に登録される |
✅ ポイント
- 通常想定される入力値をすべてカバーする。
- 異なる組み合わせ（最小値・最大値・中間値）を含める。
2. 異常系（Unexpected Cases）
不正な入力値を用いて、適切にエラー処理されるかを確認する。
| No | テスト項目 | 入力値 | 期待される結果 |
|---|---|---|---|
| 6 | 管理番号が空欄 | 管理番号: (空), 製品番号: A | エラーメッセージ表示 |
| 7 | 製品番号が空欄 | 管理番号: 2000, 製品番号: (空) | エラーメッセージ表示 |
| 8 | 管理番号が範囲外（999以下） | 管理番号: 999, 製品番号: B | エラーメッセージ表示 |
| 9 | 管理番号が範囲外（10000以上） | 管理番号: 10000, 製品番号: C | エラーメッセージ表示 |
| 10 | 製品番号が無効値 | 管理番号: 3000, 製品番号: "X" | エラーメッセージ表示 |
| 11 | 2006年以前の異常値 | 年: 2005, 製品番号: A | エラーメッセージ表示 |
| 12 | 半角英数字以外の入力 | 管理番号: 2000, 製品番号: "＠" | エラーメッセージ表示 |
✅ ポイント
- 入力項目が空欄のケースをテストする。
- 入力値の範囲外（上限・下限）をテストする。
- 定義されていない値（無効な製品番号）を入力する。
- 2006年以前/以降で条件が変わるなら、それぞれ異常系を考慮する。
3. 臨界値（Boundary Cases）
閾値付近の動作を検証し、バグを防ぐ。
| No | テスト項目 | 入力値 | 期待される結果 |
|---|---|---|---|
| 13 | 管理番号の最小境界（OK） | 管理番号: 1000, 製品番号: A | 正常に登録される |
| 14 | 管理番号の最小境界（NG） | 管理番号: 999, 製品番号: B | エラーメッセージ表示 |
| 15 | 管理番号の最大境界（OK） | 管理番号: 9999, 製品番号: C | 正常に登録される |
| 16 | 管理番号の最大境界（NG） | 管理番号: 10000, 製品番号: T | エラーメッセージ表示 |
| 17 | 2006年境界（OK） | 年: 2006, 製品番号: A | 正常に登録される |
| 18 | 2006年境界（NG） | 年: 2005, 製品番号: A | エラーメッセージ表示 |
✅ ポイント
- 「閾値の前後」を必ずテストする（1000、999、9999、10000など）。
- ソースコードで条件分岐をチェックし、その境界値を網羅する。
- 年代や数値の境界点（例：2006年）を考慮し、前後のテストケースを用意する。
2.入力項目の明確化について
テスト仕様書において、入力項目を明確に記述すること は、テストの網羅性と正確性を確保するために非常に重要です。
入力項目が曖昧だと、どの値をテストすべきかが分かりにくくなり、テストケースの抜け漏れが発生する原因 になります。
1. 入力項目の分類
入力項目を整理することで、テストすべきパターンを明確にできます。
例えば、「製品登録システム」において、以下のような入力項目があるとします。
| 項目名 | 説明 | 例 |
|---|---|---|
| 管理番号 | 製品を識別する一意の番号（4桁の数字） | 1000, 2500, 9999 |
| 製品番号 | 製品の種類を表すコード（英大文字1文字） | A, B, C, T |
| 価格 | 製品の販売価格（整数） | 1000, 2000, 50000 |
各入力項目ごとに、正常値・異常値・境界値を意識してテストケースを設計します。
2. 入力項目ごとに列を分ける
テスト仕様書では、各入力項目を明確に区別するため、入力項目ごとに列を分ける ことが重要です。
❌ 悪い例（入力項目が曖昧）
| No | テスト内容 | 入力値 | 期待される結果 |
|---|---|---|---|
| 1 | 正常な登録 | 1000, A | 正常に登録される |
| 2 | 異常値（範囲外） | 999, B | エラーメッセージ表示 |
このような表記では、どの入力項目が何の値を指しているのかが分かりにくい です。
✅ 良い例（入力項目を明確に記述）
| No | テスト内容 | 管理番号 | 製品番号 | 価格 | 期待される結果 |
|---|---|---|---|---|---|
| 1 | 正常な登録 | 1000 | A | 2000 | 正常に登録される |
| 2 | 管理番号の範囲外（最小値） | 999 | B | 5000 | エラーメッセージ表示 |
| 3 | 製品番号の無効値 | 3000 | X | 10000 | エラーメッセージ表示 |
| 4 | 価格の範囲外（最大値超過） | 5000 | C | 1000000 | エラーメッセージ表示 |
このように入力項目を明確に列分けすると、どのテストケースがどの入力項目を対象としているのかが分かりやすくなります。
3. 複数の入力項目の組み合わせを考慮
入力項目ごとに個別のテストケースを設計するだけでなく、複数の入力項目を組み合わせたテストも重要 です。
例えば、管理番号と製品番号の両方が関係するテストケースを考える場合：
組み合わせテスト（異常系）
| No | 管理番号 | 製品番号 | 期待される結果 |
|---|---|---|---|
| 1 | 空欄 | A | エラーメッセージ表示 |
| 2 | 2000 | 空欄 | エラーメッセージ表示 |
| 3 | 999 | A | エラーメッセージ表示 |
| 4 | 1000 | X | エラーメッセージ表示 |
✅ ポイント
- 入力項目の単体テストだけでなく、複数項目の組み合わせも考慮する。
- 異常値の組み合わせ（例えば、管理番号が正常でも製品番号が異常ならエラーになるか）をチェックする。
4. 仕様の変更に対応しやすくする
入力項目が明確に記述されていると、仕様変更にも柔軟に対応しやすい です。
例: 2006年以降の仕様変更
例えば、2006年以降に「製品番号 'X' の新しいルールが追加された」とします。
この場合、テスト仕様書の 「製品番号」 に関するテストケースを追加・修正するだけで対応できます。
| No | 管理番号 | 製品番号 | 年 | 期待される結果 |
|---|---|---|---|---|
| 1 | 2000 | A | 2005 | 正常に登録される |
| 2 | 2000 | X | 2005 | エラーメッセージ表示 |
| 3 | 2000 | X | 2006 | 正常に登録される |
✅ ポイント
- 「年」などの追加条件が発生した場合でも、入力項目を明確にしておけば影響範囲を特定しやすい。
- 特定の条件（例: 2006年以降）による動作の違いをテスト仕様書に反映しやすい。
5. 仕様書とソースコードの整合性を確保
テスト仕様書がソースコードと一致しているかを確認するために、入力項目をソースコードのロジックと照らし合わせて整理 する。
例：ソースコード
def validate_product(management_number, product_code, year):
if not (1000 <= management_number <= 9999):
return "管理番号が範囲外です"
if product_code not in ["A", "B", "C", "T"] and year < 2006:
return "無効な製品番号です"
return "登録成功"
この場合、テスト仕様書に「管理番号の範囲チェック」や「製品番号のバリデーション」 を確実に反映する必要があります。
3.判断条件の考慮についての具体例
テスト仕様書を作成する際、判断条件（条件分岐）が適切にカバーされているか を確認することは非常に重要です。
特に、IF文・CASE文・ルールベースの分岐が存在する場合、すべてのパターンを網羅するテストケースを作成 しないと、潜在的なバグを見逃す可能性があります。
1. 判断条件のパターンを洗い出す
まず、テスト対象のソースコードや仕様書を確認し、どのような条件分岐があるかを明確にする ことが必要です。
例えば、以下のようなルールがあるとします。
📌 ルール例：製品の割引適用
- 条件1：購入金額が 10,000 円以上なら 10% 割引
- 条件2：会員ランクが「ゴールド」の場合、さらに 5% 割引
- 条件3：2006年以降は、会員ランクに関係なく一律 8% 割引
このようなルールをテストするために、すべての条件をカバーするテストケースを設計する必要があります。
2. 条件分岐のテストケースを設計
このルールに基づき、考えられるすべての組み合わせを網羅するテストケースを作成します。
| No | 購入金額 | 会員ランク | 年 | 割引率 | 期待される結果 |
|---|---|---|---|---|---|
| 1 | 9,999 | 一般 | 2005 | 0% | 割引なし |
| 2 | 10,000 | 一般 | 2005 | 10% | 10% 割引適用 |
| 3 | 10,000 | ゴールド | 2005 | 15% | 10% + 5% 割引適用 |
| 4 | 5,000 | ゴールド | 2005 | 0% | 割引なし |
| 5 | 20,000 | ゴールド | 2006 | 8% | 一律 8% 割引適用 |
| 6 | 20,000 | 一般 | 2006 | 8% | 一律 8% 割引適用 |
✅ ポイント
- 「条件が適用される/されない」の両方のケースを網羅 する。
- 条件が変更される年（2006年）の前後をしっかりテスト する。
- 組み合わせパターン（会員ランク×購入金額×年）を考慮する。
3. 条件分岐を網羅するには
判断条件を考慮したテスト設計を行う際には、以下の手法を活用すると網羅性を高めることができます。
(1) デシジョンテーブル（決定表）を作成
デシジョンテーブルは、複数の条件とその組み合わせを整理し、抜け漏れなくテストケースを作成するための手法 です。
📌 例：製品の在庫状況による注文処理
ルール：
- 在庫がある場合、注文可能
- 在庫がないが、予約可能なら注文できる
- 在庫なし & 予約不可なら注文不可
| No | 在庫あり | 予約可能 | 期待される結果 |
|---|---|---|---|
| 1 | あり | ー | 注文可能 |
| 2 | なし | あり | 予約注文可能 |
| 3 | なし | なし | 注文不可 |
✅ ポイント
- すべての条件の組み合わせを表にして整理 すると、テストケースの漏れが減る。
- 条件が複雑な場合に特に有効 で、ルール変更にも対応しやすい。
(2) 条件分岐の境界値を考慮
条件分岐が「数値の範囲」によって決まる場合、境界値をテスト することが重要です。
📌 例：年齢による料金プラン
| No | 年齢 | 期待される料金プラン |
|---|---|---|
| 1 | 17 | 子供料金 |
| 2 | 18 | 大人料金 |
| 3 | 65 | 大人料金 |
| 4 | 66 | シニア料金 |
✅ ポイント
- 境界線（例: 18歳・65歳）の前後を必ずテスト することで、バグを検出しやすくなる。
(3) 条件の組み合わせを網羅
条件が複数ある場合、それぞれの組み合わせが適切にテストされているかを確認する。
📌 例：2006年を基準とした判断条件 例えば、システムの仕様が「2006年以降は新しいルールに従う」となっている場合、2025年と2006年の境界テストを忘れない ようにする。
| No | 入力年 | ルール適用 |
|---|---|---|
| 1 | 2005 | 旧ルール適用 |
| 2 | 2006 | 新ルール適用 |
| 3 | 2007 | 新ルール適用 |
✅ ポイント
- 仕様変更がある場合、その「境界の前後」をテストする。
- 仕様が適用されるタイミングが明確かをチェックする。
4. ソースコードとの整合性を確認
テスト仕様書を作成する際には、ソースコードの条件分岐をチェックし、それがすべてテストケースに反映されているかを確認する。
📌 例：Pythonのコード
def discount(price, member, year):
if year >= 2006:
return price * 0.92 # 8% 割引
elif price >= 10000:
return price * (0.9 if member == "一般" else 0.85) # 10% or 15% 割引
return price
📌 必要なテストケース
- year が 2006 未満・以上のケース
- price が 10,000 未満・以上のケース
- member が "一般"・"ゴールド" のケース
4. 入力値の組み合わせを考慮する際の詳細なアプローチ
ソフトウェアのテストでは、入力項目の組み合わせを適切に考慮することが重要です。
組み合わせを十分に考えないと、予期しないバグが発生するリスクがあります。
ここでは、テストケースを効率的に設計し、網羅性を高める方法を解説します。
1. 入力値の組み合わせの考え方
複数の入力項目がある場合、それぞれの組み合わせを考慮することで、期待通りに動作するか、異常が発生しないかを確認します。
例えば、「製品登録システム」では、以下のような入力項目があるとします。
| 項目名 | 説明 | 例 |
|---|---|---|
| 管理番号 | 4桁の数字 | 1000, 2000, 9999 |
| 製品番号 | 1文字の英字（A, B, C, T など） | A, B, C |
| 価格 | 1000以上の整数 | 1000, 5000, 10000 |
| 登録年 | システムに登録された年 | 2005, 2006, 2007 |
このように複数の入力値がある場合、適切な組み合わせテストが必要です。
2. 全組み合わせテスト（直積）
すべての組み合わせをテストする方法です。
網羅性が最も高いですが、組み合わせが多すぎるとテストケースの数が爆発的に増加します。
📌 例：全組み合わせ
| No | 管理番号 | 製品番号 | 価格 | 登録年 |
|---|---|---|---|---|
| 1 | 1000 | A | 1000 | 2005 |
| 2 | 1000 | A | 1000 | 2006 |
| 3 | 1000 | A | 5000 | 2005 |
| 4 | 1000 | B | 1000 | 2005 |
| 5 | 2000 | C | 5000 | 2006 |
| … | … | … | … | … |
✅ メリット
- すべてのケースを網羅できる。
❌ デメリット
- 組み合わせの数が膨大になり、現実的にテストが難しくなる。
例えば、4つの項目（管理番号 × 製品番号 × 価格 × 登録年）でそれぞれ3種類ある場合： [ 3 × 3 × 3 × 3 = 81 \text{ ケース} ] 実際のシステムでは数百・数千のケースになることが多い。
3. 直交表を用いたテスト（組み合わせ削減）
すべての組み合わせをテストするのが難しい場合、「直交表（Orthogonal Array）」 を使って最小限の組み合わせを選ぶ方法があります。
📌 例：直交表を使用した組み合わせ
| No | 管理番号 | 製品番号 | 価格 | 登録年 |
|---|---|---|---|---|
| 1 | 1000 | A | 1000 | 2005 |
| 2 | 2000 | B | 5000 | 2006 |
| 3 | 9999 | C | 10000 | 2007 |
| 4 | 1000 | B | 5000 | 2007 |
| 5 | 2000 | C | 1000 | 2005 |
✅ メリット
- 必要最低限の組み合わせを選び、テストケースを大幅に削減できる。
- 重要なケースを確実にテストできる。
❌ デメリット
- 一部の組み合わせがテスト対象から漏れる可能性がある。
4. 同値分割 & 境界値分析
入力値をグループ化し、代表値を選んでテストする方法 です。
(1) 同値分割
- 値が同じ意味を持つ範囲を**「グループ化」**し、それぞれ1つの値を代表としてテストする。
- 例えば、「価格が1000～10000の範囲」なら、1000・5000・10000の3つを代表値として選ぶ。
| クラス | 代表値 |
|---|---|
| 有効な管理番号（1000〜9999） | 1000, 5000, 9999 |
| 無効な管理番号（範囲外） | 999, 10000 |
(2) 境界値分析
- 境界部分（最小値、最大値、その前後の値）を重点的にテストする。
- バグが出やすいポイントを特定するのに有効。
| No | 管理番号 | 価格 | 期待される結果 |
|---|---|---|---|
| 1 | 999 | 1000 | エラー |
| 2 | 1000 | 1000 | 正常 |
| 3 | 9999 | 1000 | 正常 |
| 4 | 10000 | 1000 | エラー |
✅ ポイント
- 範囲の前後をテストする（例：999, 1000, 9999, 10000）。
- 有効な値だけでなく、無効な値もテストする。
5. 組み合わせを考慮した異常系テスト
異常値を組み合わせたケースもテストが重要です。
例えば、「管理番号が正常でも、製品番号が異常な場合」などのケースを考慮します。
| No | 管理番号 | 製品番号 | 価格 | 期待される結果 |
|---|---|---|---|---|
| 1 | 1000 | X | 5000 | エラーメッセージ |
| 2 | 999 | A | 1000 | エラーメッセージ |
| 3 | 10000 | C | 1000 | エラーメッセージ |
| 4 | 2000 | B | -1000 | エラーメッセージ |
✅ ポイント
- 異常値を1つずつ組み合わせてテストする（異常値の直積は多すぎるため）。
- 異常値と正常値の組み合わせを意識する。
5.AIの活用と人間の判断：具体的な方法
AIをテスト仕様書の作成・改善に活用することで、抜け漏れのチェック、テストケースの自動生成、網羅性の向上 などのメリットが得られます。しかし、AIの結果をそのまま受け入れるのではなく、人間が判断して適切に補正することが重要 です。
ここでは、AIを活用する具体的な方法と、人間がどのように判断すべきか を詳しく解説します。
1. AIを活用できる領域
AIは、以下のようなタスクで特に有効です。
| 活用領域 | 具体的な活用方法 | メリット |
|---|---|---|
| テストケースの生成 | 入力値や条件を与えて、AIにテストケースを作成させる | 網羅性を高め、作業の手間を削減 |
| 網羅性チェック | 既存のテスト仕様書をAIに解析させ、抜け漏れを指摘させる | ヒューマンエラーを防ぐ |
| 異常系・境界値の提案 | 想定外のケースや境界値をAIに提案させる | 意識しづらいケースを網羅できる |
| 仕様の矛盾検出 | ソースコードや仕様書のロジックを比較し、矛盾を検出する | 仕様ミスを早期発見 |
| 自動テストコードの生成 | 仕様書をもとに、テストコードのひな形を作成させる | 効率化 & 自動化 |
✅ ポイント
- AIに「網羅性チェック」や「異常系の提案」をさせることで、見落としを防げる。
- 単純な作業を自動化 することで、人間はより重要な部分に集中できる。
2. AIを使ってテストケースを生成する
例えば、製品登録システムのテスト仕様書を作成するときに、AIに以下のようなプロンプトを入力します。
📌 AIに依頼するプロンプト例
「管理番号（1000～9999）、製品番号（A, B, C, T）、価格（1000～10000）、登録年（2025～2027）を考慮した正常系・異常系・境界値のテストケースを作成してください。」
📌 AIが生成したテストケース（例）
| No | 管理番号 | 製品番号 | 価格 | 登録年 | 期待される結果 |
|---|---|---|---|---|---|
| 1 | 1000 | A | 1000 | 2005 | 正常に登録される |
| 2 | 999 | B | 5000 | 2006 | エラーメッセージ表示 |
| 3 | 2000 | C | -1000 | 2007 | エラーメッセージ表示 |
| 4 | 9999 | T | 10000 | 2005 | 正常に登録される |
✅ AIの出力を人間がどう判断するか
- 境界値テスト（1000, 999, 9999, 10000）が考慮されているかを確認
- 異常系（負の価格や範囲外の管理番号など）が適切に含まれているかをチェック
- ソースコードのロジックと一致しているかを検証
- 仕様変更（例：2006年以降の新ルール）に対応できているかを確認
3. AIの結果をそのまま受け入れない
AIは万能ではないため、その結果を鵜呑みにせず、人間がレビュー・修正を行う 必要があります。
📌 AIの結果に対するチェックポイント
- 仕様通りのテストケースになっているか？
→ 仕様書やソースコードを見ながら、意図しないケースがないか確認。 - テストケースの粒度は適切か？
→ 必要以上に細かすぎる or 足りないテストがないかチェック。 - 条件分岐や境界値が漏れていないか？
→ ソースコードのロジックと比較し、条件分岐の網羅性を確認。 - 異常系が適切に含まれているか？
→ AIは異常系の考慮が不十分なことがあるため、意図的にチェック。 - 最新の仕様変更に対応しているか？
→ 例えば、2006年以降のルール変更など、新しい仕様にAIが対応しているか確認。
✅ ポイント
- 「AIが生成した＝正しい」ではない！
- 人間が最終チェックをして、実際の仕様と合っているかを確認する。
4. AIと人間の役割分担
AIと人間の作業をうまく分担することで、テスト仕様書の作成が効率的になります。
| 作業 | AIが得意な部分 | 人間が判断すべき部分 |
|---|---|---|
| テストケースの生成 | テストケースのひな形を作成 | ビジネスルールに沿っているか判断 |
| 異常系の網羅チェック | 一般的な異常ケースを提案 | 仕様に基づく異常ケースを追加 |
| 組み合わせテストの設計 | 直交表などを使った効率的なテストパターンを生成 | 重要なケースを追加・調整 |
| 境界値の洗い出し | 境界値の候補をリストアップ | 仕様をもとに本当に必要な境界を選定 |
| 自動テストコード生成 | テストスクリプトのひな形作成 | 実際の環境で動作するか検証 |
✅ ポイント
- AIを「アシスタント」として使い、最終判断は人間が行う。
- 網羅性チェックや異常系の考慮など、人間の知識が必要な部分に集中する。
5. AIを活用した効果的なワークフロー
📌 効率的なテスト仕様書作成の手順
- AIに仕様を入力し、テストケースを生成させる。
- 人間がレビューし、不足・誤りがないかチェック。
- 異常系や境界値のテストケースを追加・調整する。
- ソースコードや仕様書と照らし合わせ、矛盾がないか確認。
- 必要に応じて、自動テストコードをAIに生成させる。
- 実際のテスト実施後、結果を分析し、改善点をAIにフィードバックする。
✅ このサイクルを回すことで、網羅性の高いテスト仕様書を作成できる。
まとめ
テスト仕様書の網羅性を高めることは、ソフトウェアの品質向上に直結します。
✅ 網羅性の向上
- 正常系・異常系・境界値をカバーする。
- 組み合わせテストを考慮し、ソースコードとの整合性を確認。
✅ 入力項目の明確化
- 各入力項目を整理し、個別に記述。
- 組み合わせテストを実施し、仕様変更にも対応できるようにする。
✅ 判断条件の考慮
- 条件分岐を整理し、デシジョンテーブルを活用。
- 境界値の前後をテストし、影響範囲を網羅。
✅ AIの活用と人間の判断
- AIを活用してテストケースの自動生成・網羅性チェックを行う。
- 人間が最終判断を行い、AIの提案を仕様と照らし合わせて検証。
🎯 AIをアシスタントとして活用し、精度の高いテスト仕様書を作成しよう！