1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

時短で進めるテスト仕様書作成ガイド【チェックリスト&ステップバイステップ&AI活用】

1
Posted at

時短で進めるテスト仕様書作成ガイド【チェックリスト&ステップバイステップ&AI活用】

はじめに

「テスト仕様書、どこから手をつければ...」「漏れがないか不安...」

本記事では、テスト仕様書を効率的に作成するチェックリスト、具体的な手順、AI活用のコツを完全網羅します。

コピペして即使えます。

1. 作業開始前チェックリスト

1.1 準備物チェック

□ 詳細設計書(最新版)を入手した
□ 画面仕様書/API仕様書を入手した
□ データベース設計書を入手した
□ テスト仕様書のテンプレートを準備した
□ 過去の類似機能のテスト仕様書を探した
□ テストデータ作成用のExcel/ツールを準備した
□ クライアント様のフォーマットルールを確認した
□ レビュー観点・チェックリストを入手した
□ 作業時間を確保した(目安:機能1つあたり2〜4時間)
□ AI(ChatGPT/Claude等)にアクセスできる環境を準備した

1.2 仕様理解チェック

□ 機能の目的を理解した
□ 入力項目をすべて把握した
□ 出力項目をすべて把握した
□ 処理フローを理解した
□ データベースのテーブル構造を確認した
□ 正常系の動作を把握した
□ エラーハンドリングの仕様を確認した
□ 外部連携があるか確認した
□ 権限・認証の仕様を確認した
□ 非機能要件(性能・セキュリティ)を確認した
□ 不明点をリストアップした
□ 不明点を設計者に確認した

1.3 スコープ確認チェック

□ 今回のテスト範囲を明確にした
□ 単体テスト/結合テスト/総合テストのどれか確認した
□ 必須テストケースを定義した
□ 任意テストケースを定義した
□ テストの優先度づけをした
□ テスト除外項目を明確にした
□ テスト実施環境を確認した
□ テストデータ準備方法を確認した
□ テスト期限を確認した
□ レビュー担当者・期限を確認した

2. ステップバイステップ作成手順

Step 1: 項目リストアップ(所要時間:15分)

やること:

詳細設計書から、テスト対象項目を抽出する

具体的な作業:

1. 詳細設計書を開く

2. 入力項目をExcelに転記
   | 項目名 | 型 | 桁数 | 必須/任意 | 備考 |
   |--------|----|----|---------|------|

3. 制約条件をマーキング
   - 必須項目に★マーク
   - ユニーク制約に◆マーク
   - 外部キーに▲マーク

4. 特殊な処理をメモ
   - デフォルト値設定
   - 自動採番
   - 計算項目
   - 状態遷移

AI活用のコツ:

■プロンプト例:
以下の詳細設計書から、入力項目一覧をテーブル形式で抽出してください。

【詳細設計書】
(ここに貼り付け)

【出力形式】
| 項目名 | 論理名 | 型 | 桁数/範囲 | 必須/任意 | 制約 | 備考 |

制約には、ユニーク、外部キー、デフォルト値などを記載してください。

チェックリスト:

□ すべての入力項目を抽出した
□ 必須/任意を明記した
□ 桁数/範囲を記載した
□ 制約条件を記載した
□ 特殊処理をメモした

Step 2: テストパターン決定(所要時間:20分)

やること:

各項目について、どのテストパターンが必要か決める

判定フローチャート:

項目Xについて:

必須項目?
├ YES → 正常系(1)、未入力(1)、NULL(1)、空文字(1)、空白(1) = 5パターン
└ NO  → 正常系(1)、NULL(1)、空文字(1) = 3パターン

文字数制限あり?
├ YES → 最小値(1)、最大値(1)、最小-1(1)、最大+1(1) = 4パターン追加
└ NO  → なし

形式指定あり(メール、電話等)?
├ YES → 形式不正パターン(5〜10パターン)追加
└ NO  → なし

ユニーク制約あり?
├ YES → 重複エラー(1パターン)追加
└ NO  → なし

AI活用のコツ:

■プロンプト例:
以下の項目について、必要なテストパターンをリストアップしてください。

【項目情報】
- 項目名:customer_name
- 型:文字列
- 桁数:1〜100文字
- 必須/任意:必須
- 制約:なし

【出力形式】
テストパターン一覧を番号付きで出力してください。
各パターンについて、テストデータ例も記載してください。

テストパターン早見表:

項目特性 必要なテストパターン 件数目安
必須・文字列・桁数あり 正常、未入力、NULL、空文字、空白、最小、最大、最小-1、最大+1 9件
任意・文字列・桁数あり 正常、NULL、未設定、最小、最大、最小-1、最大+1 7件
必須・数値・範囲あり 正常、未入力、NULL、最小、最大、最小-1、最大+1、型違い 8件
必須・メール形式 正常、未入力、NULL、@なし、ローカル部なし、ドメイン部なし、空白含む、日本語、@複数 9件
ユニーク制約あり 上記+重複エラー +1件

チェックリスト:

□ 全項目のテストパターンを決定した
□ 正常系パターンを定義した
□ 異常系パターンを定義した
□ 境界値パターンを定義した
□ NULLパターンを定義した
□ 組み合わせテストの要否を判断した

Step 3: テストケースID採番(所要時間:10分)

やること:

テストケースに一意のIDを付ける

ID採番ルール例:

TC-[区分]-[連番3桁]

区分:
- N:正常系(Normal)
- E:異常系(Error)
- B:境界値(Boundary)
- NULL:NULL・未定義
- SEC:セキュリティ
- PERF:パフォーマンス
- C:組み合わせ(Combination)

例:
TC-N-001:全項目正常値で登録
TC-E-001:customer_name未入力エラー
TC-B-001:customer_name最小値(1文字)

AI活用のコツ:

■プロンプト例:
以下のテストパターンに、ID(TC-[区分]-[連番])を採番してください。

【テストパターン】
1. 全項目正常値で登録
2. customer_name未入力エラー
3. customer_name NULL設定エラー
4. customer_name 1文字(最小値)
...

【出力形式】
| TC-ID | テスト項目 | 区分 |

チェックリスト:

□ 採番ルールを決定した
□ すべてのテストケースにIDを付けた
□ IDが重複していないことを確認した
□ 区分が適切であることを確認した

Step 4: 正常系テスト詳細作成(所要時間:30分)

やること:

正常系テストケースの詳細(目的、前提、手順、期待値)を書く

テンプレート:

■テストケースID:TC-N-001

■テスト目的:
[機能名]が正常に動作することを確認する。

■テスト区分:
正常系

■優先度:
高

■前提条件:
- システムが正常稼働している
- テストデータが準備されている
- [具体的な前提条件]

■テストデータ:
{
  "項目1": "値1",
  "項目2": "値2"
}

■テスト手順:
1. [操作1]
2. [操作2]
3. レスポンス/画面を確認
4. DBを確認

■期待値:
【レスポンス/画面】
- [期待される結果]

【データベース】
- [期待されるDB状態]

■確認観点:
- データ整合性が保たれること
- 処理が正常に完了すること

AI活用のコツ:

■プロンプト例:
以下の情報から、正常系テストケースの詳細を作成してください。

【機能情報】
- 機能名:顧客登録API
- エンドポイント:POST /api/customers
- 入力項目:customer_name, email, phone, age

【テスト目的】
全項目に正常値を設定して登録できることを確認

【出力形式】
- テスト目的
- 前提条件
- テストデータ(JSON形式)
- テスト手順(番号付き)
- 期待値(レスポンスとDBに分けて)
- 確認観点

時短テクニック:

1. 最初の1件を丁寧に作成
2. 以降はコピペ&修正
3. 変更箇所のみハイライト
4. レビュー時に効率的

チェックリスト:

□ テスト目的を明確に記載した
□ 前提条件を漏れなく記載した
□ テストデータが具体的である
□ テスト手順が再現可能である
□ 期待値が明確である
□ 確認観点を記載した
□ 誰が読んでも理解できる内容である

Step 5: 異常系テスト詳細作成(所要時間:40分)

やること:

異常系テストケースの詳細を書く

テンプレート:

■テストケースID:TC-E-001

■テスト目的:
[異常条件]の場合、適切なエラーハンドリングが行われることを確認する。

■テスト区分:
異常系

■優先度:
中〜高

■前提条件:
- システムが正常稼働している

■テストデータ:
{
  // customer_nameキーなし(異常データ)
  "email": "test@example.com"
}

■テスト手順:
1. 上記テストデータでAPIを呼び出す
2. エラーレスポンスを確認
3. DBを確認

■期待値:
【レスポンス】
- ステータスコード:400
- エラーメッセージ:"customer_nameは必須項目です"
- エラーコード:"VALIDATION_ERROR"

【データベース】
- データが登録されないこと

■確認観点:
- エラーメッセージが明確であること
- DBが不整合状態にならないこと

AI活用のコツ:

■プロンプト例:
以下の異常系テストケースの詳細を作成してください。

【テスト概要】
customer_nameが未入力の場合、400エラーが返却されることを確認

【機能情報】
- API:POST /api/customers
- 必須項目:customer_name, email

【出力内容】
- テスト目的
- テストデータ(JSON、異常箇所をコメント明記)
- テスト手順
- 期待値(ステータスコード、エラーメッセージ、DB状態)
- 確認観点

異常系テストの優先順位:

【高優先度】
□ 必須項目未入力
□ ユニーク制約違反
□ 外部キー制約違反
□ 権限エラー
□ 状態遷移エラー

【中優先度】
□ 文字数超過
□ 範囲外エラー
□ 形式不正
□ 型不一致

【低優先度】
□ エラーメッセージ文言詳細
□ 複数エラー同時発生時の挙動

チェックリスト:

□ どの異常条件をテストするか明確である
□ テストデータの異常箇所が明確である
□ 期待されるエラーメッセージを記載した
□ 期待されるステータスコードを記載した
□ DBが不整合にならないことを確認項目に入れた
□ セキュリティ上の情報漏洩がないことを確認項目に入れた

Step 6: 境界値・NULLテスト作成(所要時間:30分)

やること:

境界値テストとNULLテストケースを書く

境界値テスト一括生成プロンプト:

■プロンプト例:
以下の項目について、境界値テストケースを生成してください。

【項目情報】
- 項目名:customer_name
- 型:文字列
- 桁数:1〜100文字
- 必須/任意:必須

【生成するテストケース】
1. 最小値(1文字)
2. 最小値+1(2文字)
3. 最大値-1(99文字)
4. 最大値(100文字)
5. 最小値-1(0文字) ※エラー
6. 最大値+1(101文字) ※エラー

【出力形式】
各テストケースについて:
- TC-ID
- テスト目的
- テストデータ
- 期待値(成功/エラー)

NULLテスト一括生成プロンプト:

■プロンプト例:
以下の項目について、NULL・未定義テストケースを生成してください。

【項目情報】
- customer_name:必須項目
- phone:任意項目

【生成するパターン】
必須項目(customer_name):
1. NULL設定 → エラー
2. キー未設定 → エラー
3. 空文字("") → エラー
4. 空白("   ") → エラー

任意項目(phone):
1. NULL設定 → 成功
2. キー未設定 → 成功
3. 空文字("") → 仕様確認
4. 空白("   ") → 仕様確認

各テストケースの詳細を出力してください。

チェックリスト:

□ 全項目の境界値テストを作成した
□ 最小値・最大値のテストを作成した
□ 最小-1・最大+1のテストを作成した
□ 全項目のNULLテストを作成した
□ 必須項目のNULL→エラーを確認した
□ 任意項目のNULL→成功を確認した

Step 7: テストケース一覧作成(所要時間:15分)

やること:

全テストケースをサマリー表にまとめる

サマリー表テンプレート:

■テストケース一覧

| No | TC-ID | テスト区分 | テスト項目 | 優先度 | 工数(分) | 備考 |
|----|-------|-----------|-----------|--------|---------|------|
| 1 | TC-N-001 | 正常系 | 全項目正常値で登録 | 高 | 5 | |
| 2 | TC-N-002 | 正常系 | 必須項目のみで登録 | 高 | 5 | |
| 3 | TC-E-001 | 異常系 | customer_name未入力 | 高 | 3 | |
| 4 | TC-E-002 | 異常系 | customer_name NULL | 高 | 3 | |
...

【サマリ】
- 総テストケース数:XX件
- 正常系:XX件
- 異常系:XX件
- 境界値:XX件
- NULL:XX件
- 見積工数:XXX分(XX時間)

AI活用のコツ:

■プロンプト例:
以下のテストケースから、一覧表を作成してください。

【テストケース】
(ここに全テストケースのTC-IDとテスト項目を貼り付け)

【出力形式】
Excelに貼り付け可能なTSV形式で出力してください。
項目:No, TC-ID, テスト区分, テスト項目, 優先度, 工数(分)

最後に、サマリー(総件数、区分別件数、総工数)も出力してください。

チェックリスト:

□ 全テストケースを一覧化した
□ テスト区分が正しい
□ 優先度を設定した
□ 工数見積もりをした
□ サマリーを作成した
□ 抜け漏れがないか確認した

Step 8: レビュー&修正(所要時間:30分)

やること:

セルフレビュー→他者レビュー→修正

セルフレビューチェックリスト:

【網羅性】
□ すべての入力項目をテストしているか
□ 正常系・異常系・境界値・NULLをカバーしているか
□ 必須項目の未入力テストがあるか
□ ユニーク制約の重複テストがあるか
□ 状態遷移の不正遷移テストがあるか

【明確性】
□ テスト目的が明確か
□ 前提条件が具体的か
□ テストデータが具体的か
□ テスト手順が再現可能か
□ 期待値が明確か

【整合性】
□ テストケースID採番ルールが統一されているか
□ 用語が統一されているか
□ フォーマットが統一されているか

【実行可能性】
□ テストデータが準備可能か
□ テスト環境で実行可能か
□ 工数見積もりが妥当か

AI活用のコツ:

■プロンプト例:
以下のテスト仕様書をレビューしてください。

【テスト仕様書】
(ここに貼り付け)

【レビュー観点】
1. 網羅性:テストパターンに抜け漏れがないか
2. 明確性:テスト内容が具体的で再現可能か
3. 整合性:記載内容に矛盾がないか
4. 実行可能性:実際にテスト実行できる内容か

【出力形式】
- 問題点リスト(重大度:高/中/低)
- 修正案
- 追加すべきテストケース案

他者レビュー依頼時のポイント:

□ レビュー観点を明示する
□ 特に確認してほしい箇所を明記する
□ 不明点・仕様確認事項を明記する
□ レビュー期限を設定する
□ 変更履歴を記録する

Step 9: 最終調整&提出(所要時間:15分)

やること:

フォーマット調整→最終チェック→提出

最終チェックリスト:

【フォーマット】
□ クライアント様フォーマットに準拠しているか
□ 全角・半角ルールを守っているか
□ インデントルールを守っているか
□ 表記ゆれがないか
□ 誤字脱字がないか

【完成度】
□ すべてのテストケースが記載されているか
□ すべての項目に値が入っているか
□ 空欄・TODO・確認中がないか
□ レビュー指摘を反映したか

【提出準備】
□ ファイル名が正しいか
□ バージョン番号が正しいか
□ 提出先フォルダに配置したか
□ 関係者に通知したか

AI活用のコツ:

■プロンプト例:
以下のテスト仕様書の最終チェックを実施してください。

【テスト仕様書】
(ここに貼り付け)

【チェック項目】
1. 誤字脱字
2. 表記ゆれ(用語統一)
3. 全角・半角の混在
4. 空欄・TODO・確認中の有無
5. 番号の連番確認
6. フォーマット崩れ

【出力】
- 問題点リスト
- 修正案

3. AI活用の実践テクニック

3.1 詳細設計書の一括読み込み

プロンプトテンプレート:

あなたは優れたテストエンジニアです。
以下の詳細設計書から、単体テスト仕様書を作成してください。

【詳細設計書】
(ここに詳細設計書全文を貼り付け)

【作成するテスト仕様書】
1. テストケース一覧(サマリー表)
2. 正常系テストケース詳細
3. 異常系テストケース詳細
4. 境界値テストケース詳細
5. NULLテストケース詳細

【テストケースに含める項目】
- テストケースID
- テスト目的
- テスト区分
- 優先度
- 前提条件
- テストデータ
- テスト手順
- 期待値(レスポンス/画面、データベース)
- 確認観点

【テストパターン】
- 正常系:基本動作、最小構成、全項目設定
- 異常系:必須未入力、形式不正、範囲外、重複、権限エラー
- 境界値:最小値、最大値、最小-1、最大+1
- NULL:NULL設定、未設定、空文字、空白

【注意事項】
- テストケースIDは TC-[区分]-[連番] 形式
- 区分:N(正常系)、E(異常系)、B(境界値)、NULL(NULL)
- テストデータはJSON形式で具体的に記載
- エラーメッセージは具体的に記載
- 実行可能な手順を記載

まず、テストケース一覧から出力してください。

3.2 段階的な詳細化

ステップ1:項目抽出

以下の詳細設計書から、入力項目一覧を抽出してください。

【詳細設計書】
(貼り付け)

【出力形式】
| 項目名 | 型 | 桁数/範囲 | 必須/任意 | 制約 | 備考 |

ステップ2:テストパターン決定

以下の項目について、必要なテストパターンをリストアップしてください。

【項目一覧】
(ステップ1の出力を貼り付け)

【出力形式】
項目ごとに、正常系・異常系・境界値・NULLのテストパターンを列挙

ステップ3:テストケース生成

以下のテストパターンについて、テストケースの詳細を生成してください。

【テストパターン】
(ステップ2の出力を貼り付け)

【出力形式】
各テストケースの詳細(目的、前提、データ、手順、期待値)

3.3 エラーメッセージ生成

プロンプト:

以下の異常系テストケースについて、適切なエラーメッセージを生成してください。

【テストケース】
- customer_name未入力
- customer_name NULL設定
- customer_name 文字数超過(101文字)
- email形式不正
- email重複
- 存在しないcustomer_id参照
- 権限なしユーザーがアクセス

【出力形式】
| テストケース | ステータスコード | エラーメッセージ | エラーコード |

【エラーメッセージの要件】
- ユーザーフレンドリーであること
- 具体的であること
- 技術的詳細を含まないこと
- 日本語で記載

3.4 テストデータ生成

プロンプト:

以下のテストケース用のテストデータを生成してください。

【テストケース一覧】
(TC-IDとテスト項目を貼り付け)

【データ要件】
- メールアドレスは重複しないこと
- 実在しそうなデータであること
- 境界値データは正確な桁数であること
- JSON形式で出力

【出力形式】
{
  "TC-N-001": {
    "customer_name": "山田太郎",
    "email": "yamada001@example.com",
    ...
  },
  "TC-N-002": {
    ...
  }
}

3.5 レビュー&修正支援

プロンプト:

以下のテスト仕様書をレビューし、改善案を提示してください。

【テスト仕様書】
(貼り付け)

【レビュー観点】
1. 網羅性チェック
   - すべての入力項目をテストしているか
   - 正常系・異常系・境界値・NULLをカバーしているか
   - 必須項目の未入力テストがあるか
   - ユニーク制約の重複テストがあるか

2. 明確性チェック
   - テスト目的が明確か
   - テストデータが具体的か
   - 期待値が明確か

3. 実行可能性チェック
   - 手順が再現可能か
   - テストデータが準備可能か

【出力形式】
1. 問題点リスト(重大度付き)
2. 抜け漏れテストケース案
3. 改善提案
4. 修正版テスト仕様書(主要部分)

4. 時短テクニック集

4.1 テンプレート活用

正常系テンプレート:

■TC-N-XXX:[機能名]の基本動作確認

■テスト目的:
[機能名]が正常に動作することを確認する。

■前提条件:
- システムが正常稼働している
- [追加の前提条件]

■テストデータ:
[JSON or 表形式]

■テスト手順:
1. [操作]を実行
2. レスポンス/画面を確認
3. DBを確認

■期待値:
【レスポンス/画面】
- [期待結果]
【DB】
- [期待結果]

■確認観点:
- データ整合性
- 処理完了

異常系テンプレート:

■TC-E-XXX:[項目名][異常条件]エラー

■テスト目的:
[異常条件]の場合、適切なエラーが返却されることを確認する。

■前提条件:
- システムが正常稼働している

■テストデータ:
[異常データ]

■テスト手順:
1. 上記データで[操作]を実行
2. エラーレスポンスを確認
3. DBを確認

■期待値:
【レスポンス】
- ステータスコード:[400/401/403/404/409/500]
- エラーメッセージ:"[メッセージ]"
【DB】
- データが登録/更新/削除されないこと

■確認観点:
- エラーメッセージの明確性
- DB不整合の防止

4.2 コピペ&置換

手順:

1. 最初のテストケースを丁寧に作成

2. コピーして2件目を作成

3. 以下の箇所のみ置換
   - テストケースID
   - テスト項目名
   - テストデータ
   - 期待値

4. 変更箇所以外はそのまま

時短効果:

初回:30分
2件目以降:5分/件
→ 10件作成で、150分→75分(半減)

4.3 Excel関数活用

テストケースID自動採番:

A列:連番
B列:区分(N/E/B/NULL)
C列:テストケースID

C2セル:
="TC-"&B2&"-"&TEXT(A2,"000")

下にコピー
→ TC-N-001, TC-N-002...と自動採番

優先度自動判定:

E列:テスト項目
F列:優先度

F2セル:
=IF(OR(ISNUMBER(SEARCH("必須",E2)),ISNUMBER(SEARCH("重複",E2)),ISNUMBER(SEARCH("権限",E2))),"高",IF(ISNUMBER(SEARCH("境界値",E2)),"中","低"))

工数自動計算:

G列:工数(分)
H列:総工数

H2セル:
=SUM(G:G)

4.4 過去資産の流用

流用チェックリスト:

□ 類似機能のテスト仕様書を探す
□ 項目名を置換
□ テストデータを置換
□ 固有の仕様部分を修正
□ 削除すべきテストケースを削除
□ 追加すべきテストケースを追加
□ 最終チェック

流用時の注意:

□ 前回の不具合・指摘事項を確認
□ 改善すべき点を反映
□ 単純コピペで終わらせない
□ 固有仕様の見落としに注意

5. 工数見積もりガイド

5.1 機能規模別の目安

機能規模 入力項目数 テストケース数 所要時間
1〜5項目 20〜40件 2〜3時間
6〜15項目 50〜100件 4〜6時間
16項目以上 100件以上 8時間以上

5.2 作業工程別の時間配分

工程 割合 小規模 中規模 大規模
仕様理解 15% 20分 40分 80分
項目抽出 10% 15分 30分 60分
パターン決定 15% 20分 40分 80分
詳細作成 40% 50分 100分 200分
レビュー 15% 20分 40分 80分
修正 5% 10分 15分 30分
合計 100% 2.3時間 4.4時間 8.8時間

5.3 AI活用時の時短効果

工程 通常 AI活用 削減率
項目抽出 15分 5分 67%
パターン決定 20分 10分 50%
詳細作成 50分 25分 50%
レビュー 20分 10分 50%
合計(小規模) 2.3時間 1.4時間 39%

6. まとめ

6.1 成功の鍵

✓ 準備をしっかり(設計書理解、テンプレート準備)
✓ ステップバイステップで進める(一気に書かない)
✓ AIを賢く使う(丸投げせず、段階的に活用)
✓ テンプレート・過去資産を活用
✓ こまめにレビュー(最後にまとめてやらない)

6.2 避けるべき落とし穴

✗ いきなり詳細を書き始める
✗ 正常系だけ作って満足する
✗ AIの出力をそのまま使う
✗ レビューをスキップする
✗ 仕様不明点を放置する

6.3 最終チェックリスト

□ すべての入力項目をテストしているか
□ 正常系・異常系・境界値・NULLをカバーしているか
□ テストケースIDが重複していないか
□ テスト目的が明確か
□ テストデータが具体的か
□ テスト手順が再現可能か
□ 期待値が明確か
□ 誤字脱字がないか
□ フォーマットが統一されているか
□ レビュー指摘を反映したか

この手順とチェックリストで、効率的かつ高品質なテスト仕様書が作成できます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?