テストレベル別・テスト観点別 表現完全チートシート【コピペOK・チェックリスト&ヒアリングシート付】
はじめに
「単体テストと結合テストで書き方どう変える?」「ブラックボックスとホワイトボックスで何が違う?」
本記事では、テストレベル別・テスト観点別の表現集、チェックリスト、レビュー表、上司向けヒアリングシートを完全網羅します。
コピペして即使えます。
目次
- テストレベル別表現集
- テスト観点別表現集
- チェックリスト集
- レビュー表
- 上司向けヒアリングシート
- 実践コピペ集
1. テストレベル別表現集
1.1 単体テスト(Unit Test)の表現
テスト目的の書き方:
【基本パターン】
- [関数名/メソッド名]が正しく動作することを確認する
- [クラス名]の[メソッド名]が期待通りの値を返却することを確認する
- [モジュール名]が独立して正常に機能することを確認する
【具体例】
- calculateTotalPrice関数が、商品単価と数量から正しく合計金額を計算することを確認する
- CustomerValidator.validateEmail()が、不正なメール形式を適切に検出することを確認する
- UserRepositoryクラスが、データベースへの保存処理を正常に実行することを確認する
- AuthServiceのlogin()メソッドが、認証成功時にトークンを返却することを確認する
前提条件の書き方:
【基本パターン】
- テスト対象の関数/クラスが単体で実行可能な状態である
- 外部依存をモック/スタブで置き換えている
- テストデータが準備されている
【具体例】
- calculateTotalPrice関数が実装されている
- データベース接続はモックオブジェクトで置き換えている
- 外部API呼び出しはスタブで固定値を返すよう設定している
- UserRepositoryの依存関係(DBConnection)をモック化している
- テスト用の顧客データ(customer_id: 12345)を準備している
テスト手順の書き方:
【基本パターン】
1. テスト対象の関数/メソッドを呼び出す
2. 引数に[値]を渡す
3. 戻り値を検証する
4. [モックの呼び出し回数/引数]を検証する
【具体例】
1. calculateTotalPrice(1000, 3)を呼び出す
2. 戻り値が3000であることを確認する
3. 内部で税率計算が呼ばれていないことを確認する
1. CustomerValidator.validateEmail("test@example.com")を呼び出す
2. 戻り値がtrueであることを確認する
1. UserRepository.save(userData)を呼び出す
2. モックされたDBConnection.insert()が1回呼ばれることを確認する
3. insert()に渡された引数がuserDataと一致することを確認する
4. 戻り値がtrue(保存成功)であることを確認する
期待値の書き方:
【基本パターン】
- 戻り値が[値]であること
- 例外[ExceptionName]がスローされること
- [メソッド]が[N]回呼ばれること
- [メソッド]が呼ばれないこと
- 内部状態が[値]に変更されること
【具体例】
- 戻り値が3000(数値)であること
- 戻り値がtrue(真偽値)であること
- 戻り値が"登録成功"(文字列)であること
- 戻り値が{"id": 123, "status": "success"}(オブジェクト)であること
- ValidationException("メール形式が不正です")がスローされること
- NullPointerExceptionがスローされないこと
- saveメソッドが1回だけ呼ばれること
- sendEmailメソッドが呼ばれないこと
- オブジェクトのstatusプロパティが"active"から"inactive"に変更されること
ホワイトボックステストの表現:
【カバレッジ観点】
- すべての分岐(if文)を通過することを確認する
- すべてのループ(for/while)が実行されることを確認する
- 例外ハンドリング(try-catch)が動作することを確認する
【具体例】
- age < 18の分岐が実行されることを確認する(未成年フラグがtrueになる)
- age >= 18の分岐が実行されることを確認する(未成年フラグがfalseになる)
- items配列が空の場合、forループがスキップされることを確認する
- items配列に3要素ある場合、forループが3回実行されることを確認する
- DBエラー発生時、catchブロックが実行されることを確認する
- 正常時、catchブロックが実行されないことを確認する
1.2 結合テスト(Integration Test)の表現
テスト目的の書き方:
【基本パターン】
- [モジュールA]と[モジュールB]が連携して正常に動作することを確認する
- [レイヤーA]から[レイヤーB]へのデータ受け渡しが正しく行われることを確認する
- [サブシステムA]と[サブシステムB]のインターフェースが正常に機能することを確認する
【具体例】
- コントローラー層からサービス層、リポジトリ層を経由してDBまでの一連の処理が正常に動作することを確認する
- 顧客登録APIが、バリデーション→DB登録→メール送信の一連の処理を正しく実行することを確認する
- フロントエンド画面からバックエンドAPIを呼び出し、レスポンスが正しく画面に反映されることを確認する
- 注文サブシステムが在庫サブシステムと連携し、在庫引当処理が正常に完了することを確認する
- 外部決済APIとの連携が正常に機能し、決済結果が正しく記録されることを確認する
前提条件の書き方:
【基本パターン】
- 連携する各モジュールが正常に稼働している
- データベースが起動しており、接続可能である
- 外部システムとの接続が確立されている
- テストデータがDBに準備されている
【具体例】
- アプリケーションサーバーが起動している
- PostgreSQLデータベースが起動しており、接続可能である
- Redisキャッシュサーバーが起動している
- 外部決済API(Stripe)のテスト環境に接続可能である
- customersテーブルにテストユーザー(ID:12345)が登録されている
- ordersテーブルが初期化されている(データ0件)
- メール送信サーバー(SMTP)が設定されている
テスト手順の書き方:
【基本パターン】
1. [画面/API]から処理を実行する
2. [中間層/モジュール]での処理を確認する
3. [DB/外部システム]への連携を確認する
4. 処理結果を確認する
【具体例:API→DB連携】
1. POST /api/customers エンドポイントを呼び出す
2. リクエストボディに顧客情報JSONを設定する
3. APIレスポンスを受け取る
4. customersテーブルにデータが登録されたことを確認する
5. created_atカラムに現在日時が設定されていることを確認する
【具体例:画面→API→DB連携】
1. ブラウザで顧客登録画面を開く
2. 顧客名、メールアドレスを入力する
3. 「登録」ボタンをクリックする
4. APIが呼ばれることを確認する(ネットワークログ)
5. 「登録成功」メッセージが画面に表示されることを確認する
6. customersテーブルにデータが登録されたことを確認する
【具体例:複数システム連携】
1. 注文登録APIを呼び出す
2. 在庫サブシステムに在庫確認リクエストが送信されることを確認する
3. 在庫が十分な場合、在庫引当処理が実行されることを確認する
4. 決済サブシステムに決済リクエストが送信されることを確認する
5. 決済成功後、注文が確定されることを確認する
6. メール送信サブシステムに確認メール送信リクエストが送信されることを確認する
期待値の書き方:
【基本パターン】
- [モジュールA]から[モジュールB]にデータが正しく渡されること
- [DB/外部システム]に期待通りのデータが登録/送信されること
- エラー時、適切にロールバック/リトライされること
【具体例】
【API→DB連携】
- APIレスポンス:ステータスコード201、customer_id返却
- DB:customersテーブルに1件追加
- DB:登録データがリクエスト値と一致
【トランザクション制御】
- 処理途中でエラーが発生した場合、すべての変更がロールバックされること
- ordersテーブル:登録されない
- inventoryテーブル:在庫数が変更されない
- paymentsテーブル:決済記録が残らない
【外部システム連携】
- 外部決済APIに正しいパラメータが送信されること
- 決済成功時、決済IDが返却されること
- 決済IDがordersテーブルのpayment_idカラムに記録されること
ブラックボックステストの表現:
【入出力観点】
- [入力]を与えた場合、[出力]が得られることを確認する
- 内部実装に依存せず、仕様通りの動作をすることを確認する
【具体例】
- 顧客情報(名前、メール)を入力した場合、顧客IDが返却され、DBに登録されることを確認する
- メールアドレス重複の顧客を登録しようとした場合、409エラーが返却されることを確認する
- 在庫数3の商品を5個注文しようとした場合、在庫不足エラーが返却されることを確認する
- 内部的にどのようなSQL文が発行されるかは問わず、結果的に正しいデータが登録されればよい
1.3 E2Eテスト(End to End Test)の表現
テスト目的の書き方:
【基本パターン】
- ユーザーが[操作]を行った場合、システム全体が期待通りに動作することを確認する
- [ユースケース/シナリオ]が実際のシステムで正常に完結することを確認する
- 本番環境に近い環境で、エンドユーザー視点での動作を確認する
【具体例】
- 新規ユーザーが会員登録から商品購入まで、一連の操作を完了できることを確認する
- ユーザーがログインし、商品を検索し、カートに追加し、決済を完了し、注文完了メールを受信するまでの一連のフローが正常に動作することを確認する
- 管理者が管理画面から顧客データをCSVエクスポートし、ファイルをダウンロードできることを確認する
- スマートフォンブラウザで商品一覧から詳細ページを表示し、レビューを投稿できることを確認する
前提条件の書き方:
【基本パターン】
- 本番環境に近いテスト環境が構築されている
- 全サブシステムが稼働している
- テストユーザー/テストデータが準備されている
- ブラウザ/デバイスが準備されている
【具体例】
- ステージング環境が構築され、すべてのサービスが起動している
- フロントエンド、バックエンドAPI、データベース、外部連携サービスがすべて稼働している
- テストユーザーアカウント(test_user@example.com)が登録されている
- テスト用クレジットカード番号が準備されている
- ChromeブラウザでSeleniumが実行可能である
- iPhoneシミュレーターが起動している
テスト手順の書き方:
【基本パターン】
1. [画面]を開く
2. [入力/操作]を行う
3. [画面遷移/表示]を確認する
4. 一連の操作を完了する
5. 最終結果を確認する
【具体例:会員登録→商品購入シナリオ】
1. トップページ(https://example.com)をブラウザで開く
2. 「新規登録」リンクをクリックする
3. 会員登録画面が表示されることを確認する
4. メールアドレス、パスワードを入力する
5. 「登録」ボタンをクリックする
6. 確認メールが送信されることを確認する(メールボックス確認)
7. 確認メール内のリンクをクリックする
8. ログイン画面が表示されることを確認する
9. メールアドレス、パスワードを入力してログインする
10. ダッシュボード画面が表示されることを確認する
11. 「商品一覧」メニューをクリックする
12. 商品一覧が表示されることを確認する
13. 商品「サンプル商品A」をクリックする
14. 商品詳細画面が表示されることを確認する
15. 「カートに追加」ボタンをクリックする
16. 「カートに追加しました」メッセージが表示されることを確認する
17. カートアイコンに「1」のバッジが表示されることを確認する
18. カートアイコンをクリックする
19. カート画面が表示され、商品が1件表示されることを確認する
20. 「購入手続きへ」ボタンをクリックする
21. 配送先入力画面が表示されることを確認する
22. 配送先情報を入力する
23. 「支払い方法へ」ボタンをクリックする
24. 支払い方法選択画面が表示されることを確認する
25. クレジットカード情報を入力する
26. 「注文確定」ボタンをクリックする
27. 注文完了画面が表示されることを確認する
28. 注文番号が表示されることを確認する
29. 注文完了メールが受信されることを確認する(メールボックス確認)
期待値の書き方:
【基本パターン】
- 一連の操作が完了すること
- 各画面が正しく表示されること
- データが正しく保存されること
- 外部連携(メール、決済等)が正常に動作すること
- ユーザー視点で期待通りの結果が得られること
【具体例】
【画面表示】
- すべての画面が3秒以内に表示されること
- 画面レイアウトが崩れていないこと
- エラーメッセージが表示されないこと
- ローディング中は適切なスピナーが表示されること
【データ保存】
- usersテーブルに新規ユーザーが登録されていること
- ordersテーブルに注文データが登録されていること
- order_itemsテーブルに注文明細が登録されていること
- inventoryテーブルの在庫数が減少していること
【外部連携】
- 注文完了メールが受信されること
- メール件名が「ご注文ありがとうございます」であること
- メール本文に注文番号が記載されていること
- クレジットカード決済が成功していること(決済ログ確認)
【ユーザー体験】
- ページ遷移がスムーズであること
- ボタンクリック後、適切なフィードバックがあること
- エラー時、わかりやすいメッセージが表示されること
2. テスト観点別表現集
2.1 正常系テストの表現
コピペ用テンプレート:
■テスト目的:
[機能名]が正常に動作することを確認する。
■テストデータ:
- [項目1]:正常値(例:[具体的な値])
- [項目2]:正常値(例:[具体的な値])
■期待値:
- 処理が成功すること
- [成功レスポンス/画面]が返却/表示されること
- データが正しく保存されること
バリエーション:
【最小構成パターン】
■テスト目的:
必須項目のみを設定した場合、正常に登録できることを確認する。
■テストデータ:
- customer_name:"山田太郎"(必須項目)
- email:"yamada@example.com"(必須項目)
- phone:未設定(任意項目)
- age:未設定(任意項目)
■期待値:
- ステータスコード:201
- DB:任意項目はNULLで登録される
【全項目設定パターン】
■テスト目的:
すべての項目を設定した場合、正常に登録できることを確認する。
■テストデータ:
- customer_name:"田中花子"
- email:"tanaka@example.com"
- phone:"09012345678"
- age:30
■期待値:
- ステータスコード:201
- DB:すべての項目が設定される
【デフォルト値パターン】
■テスト目的:
項目を未設定の場合、デフォルト値が適用されることを確認する。
■テストデータ:
- customer_name:"佐藤次郎"
- email:"sato@example.com"
- status:未設定(デフォルト値="active")
■期待値:
- DB:statusカラムに"active"が設定される
2.2 異常系テストの表現
必須項目エラー:
■テスト目的:
[項目名]が未入力の場合、適切なバリデーションエラーが返却されることを確認する。
■テストデータ:
{
// "customer_name"キーなし(異常)
"email": "test@example.com"
}
■期待値:
- ステータスコード:400
- エラーメッセージ:"customer_nameは必須項目です"
- エラーコード:"VALIDATION_ERROR"
- DB:データが登録されないこと
形式不正エラー:
■テスト目的:
[項目名]の形式が不正な場合、バリデーションエラーが返却されることを確認する。
■テストデータ:
{
"customer_name": "山田太郎",
"email": "invalid-email" // @なし(異常)
}
■期待値:
- ステータスコード:400
- エラーメッセージ:"メールアドレスの形式が不正です"
- DB:データが登録されないこと
重複エラー:
■テスト目的:
既に登録済みの[項目名]を登録しようとした場合、重複エラーが返却されることを確認する。
■前提条件:
- email:"duplicate@example.com"が既にDB登録済み
■テストデータ:
{
"customer_name": "重複太郎",
"email": "duplicate@example.com" // 既存と同じ(異常)
}
■期待値:
- ステータスコード:409
- エラーメッセージ:"このメールアドレスは既に使用されています"
- DB:新規データは登録されない(既存データのみ)
権限エラー:
■テスト目的:
権限のないユーザーが[操作]を実行した場合、権限エラーが返却されることを確認する。
■前提条件:
- 一般ユーザー(role="user")でログイン済み
■テスト手順:
1. 管理者専用API DELETE /api/users/12345 を呼び出す
■期待値:
- ステータスコード:403
- エラーメッセージ:"この操作を実行する権限がありません"
- DB:データが削除されない
存在しないデータエラー:
■テスト目的:
存在しない[ID/キー]を指定した場合、404エラーが返却されることを確認する。
■テストデータ:
- customer_id:99999(DBに存在しない)
■テスト手順:
1. GET /api/customers/99999 を呼び出す
■期待値:
- ステータスコード:404
- エラーメッセージ:"指定された顧客が見つかりません"
2.3 NULLテストの表現
必須項目にNULL:
■テスト目的:
必須項目[項目名]にNULLを設定した場合、バリデーションエラーが返却されることを確認する。
■テストデータ:
{
"customer_name": null, // NULL(異常)
"email": "test@example.com"
}
■期待値:
- ステータスコード:400
- エラーメッセージ:"customer_nameは必須項目です"
- DB:データが登録されない
■確認観点:
- NULLと未設定を区別してエラーメッセージが返却されること
任意項目にNULL:
■テスト目的:
任意項目[項目名]にNULLを設定した場合、正常に登録できることを確認する。
■テストデータ:
{
"customer_name": "山田太郎",
"email": "yamada@example.com",
"phone": null, // NULL(任意項目なので正常)
"age": null
}
■期待値:
- ステータスコード:201
- DB:phoneカラム、ageカラムがNULLで登録される
■確認観点:
- NULLが正しく処理されること(エラーにならない)
キー未設定:
■テスト目的:
任意項目[項目名]のキー自体が未設定の場合、正常に登録できることを確認する。
■テストデータ:
{
"customer_name": "田中花子",
"email": "tanaka@example.com"
// phoneキー自体がない
}
■期待値:
- ステータスコード:201
- DB:phoneカラムがNULLで登録される
■確認観点:
- キー未設定とNULL設定が同じ扱いになること
2.4 空白・空文字テストの表現
空文字(""):
■テスト目的:
[項目名]に空文字("")を設定した場合、[バリデーションエラー/NULL変換]となることを確認する。
■テストデータ:
{
"customer_name": "", // 空文字(異常の可能性)
"email": "test@example.com"
}
■期待値(バリデーションエラーの場合):
- ステータスコード:400
- エラーメッセージ:"customer_nameは1文字以上入力してください"
■期待値(NULL変換の場合):
- ステータスコード:201
- DB:customer_nameカラムがNULLで登録される
■確認観点:
- 空文字の扱いを仕様書で確認すること
空白文字(" "):
■テスト目的:
[項目名]に空白文字のみ(" ")を設定した場合、バリデーションエラーが返却されることを確認する。
■テストデータ:
{
"customer_name": " ", // 空白3文字(異常)
"email": "test@example.com"
}
■期待値:
- ステータスコード:400
- エラーメッセージ:"customer_nameに空白のみは使用できません"
■確認観点:
- トリム処理後に空文字になることを検出できること
- または、トリム処理されずに" "のまま保存される場合、その挙動を確認すること
全角スペース(" "):
■テスト目的:
[項目名]に全角スペースのみを設定した場合、[エラー/そのまま登録]となることを確認する。
■テストデータ:
{
"customer_name": " ", // 全角スペース2文字
"email": "test@example.com"
}
■期待値:
- 仕様に応じて、エラーまたは登録を確認
- トリム処理の有無を確認
2.5 その他のテスト観点
境界値テスト:
■テスト目的:
[項目名]に最小値[値]を設定した場合、正常に登録できることを確認する。
■テストデータ:
{
"customer_name": "あ", // 1文字(最小値)
"email": "test@example.com"
}
■期待値:
- ステータスコード:201
- DB:customer_nameが"あ"で登録される
■確認観点:
- 最小文字数でも正常に動作すること
- 文字化けしないこと
特殊文字テスト:
■テスト目的:
[項目名]に特殊文字を含む値を設定した場合、[正常/エラー]となることを確認する。
■テストデータ:
{
"customer_name": "山田<script>alert('XSS')</script>太郎",
"email": "test@example.com"
}
■期待値(セキュリティ対策済みの場合):
- ステータスコード:201
- DB:特殊文字がエスケープされて登録される
- または、ステータスコード:400(特殊文字使用不可エラー)
■確認観点:
- XSS攻撃が防止されること
- 特殊文字が適切に処理されること
SQLインジェクション対策テスト:
■テスト目的:
[項目名]にSQL文を含む値を設定した場合、SQLインジェクションが防止されることを確認する。
■テストデータ:
{
"customer_name": "'; DROP TABLE customers; --",
"email": "test@example.com"
}
■期待値:
- ステータスコード:201または400
- DB:customersテーブルが削除されない
- DB:customer_nameに文字列として登録される(プリペアドステートメント使用)
■確認観点:
- SQL文が実行されないこと
- 文字列としてエスケープされること
同時実行・排他制御テスト:
■テスト目的:
複数のリクエストが同時に同一データを更新しようとした場合、排他制御が正常に機能することを確認する。
■前提条件:
- 在庫数10の商品(product_id:12345)が存在
- versionカラム=1(楽観的ロック)
■テスト手順:
1. トランザクション1:在庫引当5個を開始
2. トランザクション2:在庫引当3個を開始
3. トランザクション1:コミット
4. トランザクション2:コミット試行
■期待値:
- トランザクション1:成功、在庫数=5、version=2
- トランザクション2:409エラー"在庫情報が更新されています"
- 最終在庫数:5(トランザクション1のみ反映)
■確認観点:
- 楽観的ロックが機能すること
- データ整合性が保たれること
大量データテスト:
■テスト目的:
[N]件のデータを処理した場合、規定時間内に完了することを確認する。
■テストデータ:
- 10000件の顧客データCSV
■テスト手順:
1. 開始時刻を記録
2. 一括登録APIを呼び出す
3. 完了時刻を記録
4. 処理時間を算出
■期待値:
- 処理時間:60秒以内
- DB:10000件すべて登録される
- メモリ使用量:1GB以内
- エラーが発生しない
■確認観点:
- パフォーマンス要件を満たすこと
- メモリリークが発生しないこと
3. チェックリスト集
3.1 単体テスト作成チェックリスト
【テスト設計】
□ すべての public メソッドをテストしているか
□ すべての分岐(if/switch)をカバーしているか
□ 正常系テストがあるか
□ 異常系テスト(例外スロー)があるか
□ 境界値テストがあるか
□ NULLパラメータテストがあるか
【テストコード品質】
□ テストメソッド名が明確か(何をテストしているか分かるか)
□ 1テストケース=1観点になっているか
□ アサーション(検証)が明確か
□ テストデータが具体的か
□ モック/スタブが適切に使われているか
□ テストが独立しているか(他テストに依存していないか)
【カバレッジ】
□ ステートメントカバレッジ:80%以上
□ ブランチカバレッジ:70%以上
□ 重要な処理は100%カバーしているか
【保守性】
□ テストが自動実行可能か
□ テストが高速に実行できるか(1テスト数秒以内)
□ テスト失敗時のエラーメッセージが分かりやすいか
□ テストコードが読みやすいか
3.2 結合テスト作成チェックリスト
【テスト範囲】
□ 連携するすべてのモジュールを含んでいるか
□ データベース連携を含んでいるか
□ 外部システム連携を含んでいるか(該当する場合)
□ トランザクション制御をテストしているか
□ エラーハンドリング(ロールバック)をテストしているか
【データ準備】
□ テストデータベースが準備されているか
□ テストデータが投入されているか
□ マスタデータが準備されているか
□ テスト実行後のクリーンアップ方法が定義されているか
【正常系】
□ 主要なユースケースをカバーしているか
□ データの受け渡しが正しいか検証しているか
□ DB登録/更新/削除が正しいか検証しているか
【異常系】
□ DB接続エラー時の挙動をテストしているか
□ 外部システムエラー時の挙動をテストしているか
□ トランザクションロールバックを検証しているか
□ リトライ処理をテストしているか(該当する場合)
【環境】
□ テスト環境が本番に近いか
□ テスト環境が独立しているか(他チームと干渉しないか)
□ テスト実行が自動化されているか
3.3 E2Eテスト作成チェックリスト
【シナリオ設計】
□ 主要なユーザーシナリオをカバーしているか
□ エンドユーザー視点のテストになっているか
□ ビジネスクリティカルなフローを含んでいるか
【テスト環境】
□ 本番に近い環境が構築されているか
□ すべてのサブシステムが稼働しているか
□ 外部連携サービスが利用可能か(またはモック化されているか)
□ テストデータが準備されているか
【画面操作】
□ 主要な画面遷移をカバーしているか
□ フォーム入力・送信をテストしているか
□ ボタン・リンククリックをテストしているか
□ 検証(アサーション)が適切に入っているか
【ブラウザ/デバイス】
□ 対象ブラウザでテストしているか(Chrome, Firefox, Safari等)
□ 対象デバイスでテストしているか(PC, スマホ, タブレット)
□ レスポンシブ対応を確認しているか
【外部連携】
□ メール送信をテストしているか(該当する場合)
□ 決済処理をテストしているか(該当する場合)
□ ファイルアップロード/ダウンロードをテストしているか(該当する場合)
【自動化】
□ テストが自動実行可能か
□ CI/CDパイプラインに組み込まれているか
□ テスト失敗時のスクリーンショット取得があるか
□ テスト実行時間が許容範囲内か(長すぎないか)
3.4 テスト観点別チェックリスト
正常系チェックリスト:
□ 基本的な正常動作をテストしているか
□ 必須項目のみのパターンをテストしているか
□ 全項目設定のパターンをテストしているか
□ デフォルト値が適用されることをテストしているか
□ 正常な境界値(最小・最大)をテストしているか
□ 任意項目のNULL/未設定をテストしているか
異常系チェックリスト:
□ 必須項目未入力エラーをテストしているか
□ 形式不正エラーをテストしているか
□ 文字数超過/不足エラーをテストしているか
□ 範囲外エラーをテストしているか
□ 型不一致エラーをテストしているか
□ 重複エラーをテストしているか(ユニーク制約)
□ 外部キー制約違反をテストしているか
□ 権限エラーをテストしているか
□ 存在しないデータ参照エラーをテストしているか
□ 状態遷移エラーをテストしているか
NULLテストチェックリスト:
□ 必須項目にNULL設定→エラーを確認しているか
□ 必須項目のキー未設定→エラーを確認しているか
□ 任意項目にNULL設定→正常を確認しているか
□ 任意項目のキー未設定→正常を確認しているか
□ 空文字("")の扱いを確認しているか
□ 空白文字(" ")の扱いを確認しているか
セキュリティテストチェックリスト:
□ SQLインジェクション対策をテストしているか
□ XSS対策をテストしているか
□ CSRF対策をテストしているか
□ 認証・認可チェックをテストしているか
□ パスワードのハッシュ化を確認しているか
□ 機密情報の漏洩防止を確認しているか
□ セッション管理を確認しているか
パフォーマンステストチェックリスト:
□ レスポンスタイムを測定しているか
□ 大量データ処理をテストしているか
□ 同時実行をテストしているか
□ メモリ使用量を確認しているか
□ CPU使用率を確認しているか
□ タイムアウト処理をテストしているか
4. レビュー表
4.1 単体テスト仕様書レビュー表
【レビュー情報】
レビュー日:___________
レビュアー:___________
作成者:___________
ドキュメント名:___________
【網羅性チェック】(各項目:OK/NG/N/A)
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 1 | すべてのpublicメソッドをテストしているか | | |
| 2 | すべての分岐をカバーしているか | | |
| 3 | 正常系テストがあるか | | |
| 4 | 異常系テストがあるか | | |
| 5 | 境界値テストがあるか | | |
| 6 | NULLパラメータテストがあるか | | |
| 7 | 例外スローのテストがあるか | | |
【明確性チェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 8 | テスト目的が明確か | | |
| 9 | テストデータが具体的か | | |
| 10 | 期待値が明確か | | |
| 11 | テストケースIDが適切か | | |
| 12 | 用語が統一されているか | | |
【品質チェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 13 | モック/スタブが適切に定義されているか | | |
| 14 | テストが独立しているか | | |
| 15 | アサーションが適切か | | |
| 16 | カバレッジ目標を満たしているか | | |
【指摘事項】
| No | 重大度 | 指摘内容 | 修正案 |
|----|--------|---------|--------|
| 1 | 高/中/低 | | |
| 2 | 高/中/低 | | |
【総合評価】
□ 承認(修正不要)
□ 条件付き承認(軽微な修正後に承認)
□ 差し戻し(大幅な修正が必要)
【コメント】
レビュアーサイン:___________
4.2 結合テスト仕様書レビュー表
【レビュー情報】
レビュー日:___________
レビュアー:___________
作成者:___________
ドキュメント名:___________
【スコープチェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 1 | 連携範囲が明確に定義されているか | | |
| 2 | テスト対象のモジュールがすべて含まれているか | | |
| 3 | データベース連携をテストしているか | | |
| 4 | 外部システム連携をテストしているか(該当時) | | |
| 5 | トランザクション制御をテストしているか | | |
【シナリオチェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 6 | 主要なユースケースをカバーしているか | | |
| 7 | データフローが明確か | | |
| 8 | 正常系シナリオが十分か | | |
| 9 | 異常系シナリオが十分か | | |
| 10 | エラーハンドリングをテストしているか | | |
【データチェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 11 | テストデータ準備方法が明確か | | |
| 12 | テストデータが具体的か | | |
| 13 | 前提条件が明確か | | |
| 14 | クリーンアップ方法が定義されているか | | |
【期待値チェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 15 | API/画面の期待値が明確か | | |
| 16 | DB状態の期待値が明確か | | |
| 17 | 外部連携の期待値が明確か | | |
【指摘事項】
| No | 重大度 | 指摘内容 | 修正案 |
|----|--------|---------|--------|
| 1 | 高/中/低 | | |
【総合評価】
□ 承認
□ 条件付き承認
□ 差し戻し
レビュアーサイン:___________
4.3 E2Eテスト仕様書レビュー表
【レビュー情報】
レビュー日:___________
レビュアー:___________
作成者:___________
ドキュメント名:___________
【シナリオチェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 1 | ユーザー視点のシナリオになっているか | | |
| 2 | ビジネスクリティカルなフローを含むか | | |
| 3 | 主要な画面遷移をカバーしているか | | |
| 4 | エンドツーエンドで完結しているか | | |
| 5 | 複数のサブシステムを跨いでいるか | | |
【操作手順チェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 6 | 操作手順が具体的か | | |
| 7 | 操作手順が再現可能か | | |
| 8 | 画面要素(ボタン、リンク等)が特定されているか | | |
| 9 | 入力値が具体的か | | |
| 10 | 検証ポイントが適切に配置されているか | | |
【環境・ツールチェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 11 | テスト環境が明確か | | |
| 12 | 使用ブラウザ/デバイスが明確か | | |
| 13 | 自動化ツールが定義されているか(該当時) | | |
| 14 | 外部連携の扱いが明確か | | |
【期待値チェック】
| No | チェック項目 | 判定 | 備考 |
|----|------------|------|------|
| 15 | 画面表示の期待値が明確か | | |
| 16 | データ保存の期待値が明確か | | |
| 17 | メール/通知の期待値が明確か(該当時) | | |
| 18 | ユーザー体験の期待値が明確か | | |
【指摘事項】
| No | 重大度 | 指摘内容 | 修正案 |
|----|--------|---------|--------|
| 1 | 高/中/低 | | |
【総合評価】
□ 承認
□ 条件付き承認
□ 差し戻し
レビュアーサイン:___________
5. 上司向けヒアリングシート
5.1 テスト仕様書作成前ヒアリングシート
【基本情報】
ヒアリング日:___________
ヒアリング対象者:___________(上司・PM・設計者)
記録者:___________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【1. テスト範囲・スコープ】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Q1. 今回作成するテストレベルはどれですか?(複数選択可)
□ 単体テスト
□ 結合テスト
□ E2Eテスト
□ その他:___________
Q2. テスト対象の機能/モジュールは何ですか?
回答:
Q3. テスト範囲外(今回対象外)の項目はありますか?
回答:
Q4. テストの優先度はどのように設定しますか?
□ すべて同等
□ 機能重要度で優先度づけ
□ その他:___________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【2. テストアプローチ】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Q5. ホワイトボックステストとブラックボックステスト、どちらを中心にしますか?
□ ホワイトボックス(内部構造を意識)
□ ブラックボックス(入出力のみ)
□ 両方
□ わからない・相談したい
Q6. カバレッジの目標はありますか?
□ ステートメントカバレッジ:____%
□ ブランチカバレッジ:____%
□ 特に指定なし
Q7. テストの自動化は必要ですか?
□ 必要(ツール:___________)
□ 不要(手動テストのみ)
□ 検討中
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【3. テスト観点】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Q8. 以下のテスト観点について、重点的にテストすべき項目はありますか?
正常系:
□ 基本動作
□ 最小構成
□ 全項目設定
□ その他:___________
異常系:
□ 必須項目未入力
□ 形式不正
□ 重複エラー
□ 権限エラー
□ その他:___________
境界値:
□ 最小値・最大値
□ 範囲外
□ その他:___________
NULL・空白:
□ NULL設定
□ 空文字
□ 空白文字
□ その他:___________
セキュリティ:
□ SQLインジェクション
□ XSS
□ 認証・認可
□ その他:___________
パフォーマンス:
□ レスポンスタイム
□ 大量データ
□ 同時実行
□ その他:___________
Q9. 上記以外で、特に注意してテストすべき観点はありますか?
回答:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【4. テストデータ・環境】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Q10. テストデータはどのように準備しますか?
□ 自分で作成
□ 提供される(提供元:___________)
□ 本番データのコピー
□ その他:___________
Q11. テスト環境は用意されていますか?
□ 用意されている(環境:___________)
□ これから構築する
□ ローカル環境で実施
□ その他:___________
Q12. データベースは使用しますか?
□ 実DB(種類:___________)
□ モック/スタブ
□ H2などのインメモリDB
□ 使用しない
Q13. 外部システム連携はありますか?
□ ある(システム名:___________)
└ 連携方法:□実システム □モック □スタブ
□ ない
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【5. ドキュメント・フォーマット】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Q14. テスト仕様書のフォーマットは指定がありますか?
□ ある(テンプレート:___________)
□ ない(任意)
□ 過去の資産を参考にする
Q15. テスト仕様書に必須で含めるべき項目は何ですか?
□ テスト目的
□ 前提条件
□ テストデータ
□ テスト手順
□ 期待値
□ その他:___________
Q16. 記載のルール・注意点はありますか?
(例:全角・半角、インデント、用語統一など)
回答:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【6. スケジュール・成果物】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Q17. テスト仕様書作成の期限はいつですか?
期限:___________
Q18. レビューのスケジュールは?
レビュー依頼日:___________
レビュー完了希望日:___________
Q19. 成果物として提出するものは?
□ テスト仕様書(Excel/Word/その他:___)
□ テストケース一覧
□ テストコード
□ その他:___________
Q20. テスト実施も担当しますか?
□ はい(実施期限:___________)
□ いいえ(テスト仕様書作成のみ)
□ 未定
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【7. 参考資料・不明点】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Q21. 参考にすべき資料はありますか?
□ 詳細設計書(場所:___________)
□ API仕様書(場所:___________)
□ 画面仕様書(場所:___________)
□ DB設計書(場所:___________)
□ 過去のテスト仕様書(場所:___________)
□ その他:___________
Q22. 現時点での不明点・懸念点はありますか?
回答:
Q23. その他、連絡事項・要望はありますか?
回答:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【確認事項】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
次回打ち合わせ:___________(必要に応じて)
緊急連絡先:___________
質問方法:□Slack □メール □対面 □その他:___
記録者サイン:___________
上司サイン:___________
5.2 仕様不明点確認シート
【仕様確認シート】
日付:___________
確認者:___________
確認先:___________(上司・設計者・PM)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【確認項目リスト】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■確認No.1
【対象機能/項目】
【質問内容】
【背景・理由】
【回答】
【対応】
□ テスト仕様書に反映
□ 設計書の修正依頼
□ その他:___________
---
■確認No.2
【対象機能/項目】
【質問内容】
【背景・理由】
【回答】
【対応】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【よくある確認項目テンプレート】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□ 任意項目に空文字("")を設定した場合、エラーにするかNULL変換するか?
□ 任意項目のキー未設定とNULL設定は同じ扱いか?
□ デフォルト値はいつ設定されるか?(登録時/初回取得時/その他)
□ 重複チェックは大文字小文字を区別するか?
□ 日付の形式は?(YYYY-MM-DD / YYYY/MM/DD / その他)
□ エラーメッセージの文言は?(仕様書に記載がない場合)
□ トランザクション制御の範囲は?
□ ロールバック条件は?
□ リトライ処理はあるか?(ある場合、回数・間隔は?)
□ 同時実行時の制御方法は?(楽観的ロック/悲観的ロック/なし)
□ セッションタイムアウト時間は?
□ ファイルアップロードの最大サイズは?
□ 対応する文字コードは?(UTF-8/Shift_JIS/その他)
□ 改行コードは?(LF/CRLF/CR)
□ NULL、空文字、ゼロ、falseの扱いの違いは?
確認者サイン:___________
回答者サイン:___________
6. 実践コピペ集
6.1 単体テスト即使いテンプレート
■テストケースID:UT-001
■テスト対象:
[クラス名].[メソッド名]
■テスト目的:
[メソッド名]が正常に動作することを確認する。
■テスト区分:
単体テスト / 正常系
■テストアプローチ:
ホワイトボックス
■前提条件:
- [メソッド名]が実装されている
- 依存関係がモック化されている
■テストデータ:
- 引数1:[値]
- 引数2:[値]
■テスト手順:
1. [メソッド名]([引数])を呼び出す
2. 戻り値を検証する
3. モックの呼び出しを検証する
■期待値:
- 戻り値:[期待値]
- [モック名]が[N]回呼ばれること
- [モック名]の引数が[期待値]であること
■確認観点:
- 戻り値が正しいこと
- 副作用がないこと
6.2 結合テスト即使いテンプレート
■テストケースID:IT-001
■テスト対象:
[API名] または [画面名→API→DB]
■テスト目的:
[モジュールA]から[モジュールB]を経由して[モジュールC]まで、一連の処理が正常に動作することを確認する。
■テスト区分:
結合テスト / 正常系
■テストアプローチ:
ブラックボックス
■前提条件:
- すべてのモジュールが起動している
- データベースが接続可能である
- テストデータが準備されている
■テストデータ:
{
"項目1": "値1",
"項目2": "値2"
}
■テスト手順:
1. [API/画面]を呼び出す/開く
2. テストデータを入力/送信する
3. レスポンス/画面を確認する
4. データベースを確認する
■期待値:
【レスポンス/画面】
- ステータスコード/メッセージ:[値]
【データベース】
- [テーブル名]:[期待される状態]
■確認観点:
- データの受け渡しが正しいこと
- トランザクションが正常にコミットされること
6.3 E2Eテスト即使いテンプレート
■テストケースID:E2E-001
■テストシナリオ:
[ユーザーが○○する]シナリオ
■テスト目的:
ユーザーが[操作]を行った場合、システム全体が期待通りに動作することを確認する。
■テスト区分:
E2Eテスト / 正常系
■テスト環境:
- 環境:[ステージング/本番相当]
- ブラウザ:[Chrome/Firefox/Safari]
- デバイス:[PC/スマホ/タブレット]
■前提条件:
- すべてのサービスが稼働している
- テストユーザーが登録されている
- テストデータが準備されている
■テスト手順:
1. [画面URL]を開く
2. [操作1]を行う
3. [画面/メッセージ]が表示されることを確認する
4. [操作2]を行う
5. [画面/メッセージ]が表示されることを確認する
...
N. 最終結果を確認する
■期待値:
【画面表示】
- [画面名]が表示されること
- [要素名]に[値]が表示されること
【データ保存】
- [テーブル名]に[データ]が保存されること
【外部連携】
- [メール/通知]が送信されること
■確認観点:
- ユーザー操作が完結すること
- 各画面が正しく表示されること
- データが正しく保存されること
7. まとめ
7.1 テストレベル別使い分け早見表
| 項目 | 単体テスト | 結合テスト | E2Eテスト |
|---|---|---|---|
| 対象範囲 | 関数/メソッド単位 | モジュール間連携 | システム全体 |
| テスト観点 | 内部ロジック | データ受け渡し | ユーザーシナリオ |
| アプローチ | ホワイトボックス中心 | ブラックボックス中心 | ブラックボックス |
| 外部依存 | モック/スタブ化 | 一部実システム | 実システム |
| 実行速度 | 高速(秒単位) | 中速(分単位) | 低速(分〜時間単位) |
| 自動化 | 容易 | やや難 | 難 |
| 作成タイミング | 実装と並行 | 実装後 | 全機能完成後 |
7.2 テスト観点別優先度
| 観点 | 単体 | 結合 | E2E | 備考 |
|---|---|---|---|---|
| 正常系 | 高 | 高 | 高 | 必須 |
| 異常系(必須未入力) | 高 | 高 | 中 | 重要 |
| 異常系(形式不正) | 高 | 高 | 中 | 重要 |
| 境界値 | 高 | 中 | 低 | 単体で重点的に |
| NULL | 高 | 中 | 低 | 単体で重点的に |
| セキュリティ | 中 | 高 | 高 | 結合・E2Eで重点的に |
| パフォーマンス | 低 | 中 | 高 | E2Eで重点的に |
7.3 最終チェックリスト
□ テストレベルに応じた表現を使っているか
□ テスト観点が網羅されているか
□ 上司とのヒアリングは完了しているか
□ 不明点は解消されているか
□ チェックリストで自己レビューしたか
□ レビュー表を使ってレビュー準備したか
□ テンプレートを活用して効率化したか
□ コピペ後、必ず内容を確認したか
このチートシートで、あらゆるテストレベル・テスト観点に対応できます!