【新人必見】仕様書からテストケースを作る思考プロセス完全ガイド - Qiita

【新人必見】仕様書からテストケースを作る思考プロセス完全ガイド #テスト - Qiita 1 いいねしたユーザー一覧へ移動 1 X（Twitter）でシェアする Facebookでシェアする はてなブックマークに追加する more_horiz 記事を削除する close 一度削除した記事は復旧できません。 この記事の編集中の下書きも削除されます。 削除してよろしいですか？ キャンセル 削除する delete @ yukikoblog8376 ( yukiko@一流のIT研修講師を目指し学習中 ) 【新人必見】仕様書からテストケースを作る思考プロセス完全ガイド テスト 1 投稿日 2026年02月13日 【新人必見】仕様書からテストケースを作る思考プロセス完全ガイド はじめに こんにちは！ 新人エンジニアの皆さん、こんな経験ありませんか？ 「仕様書を渡されて、『単体テスト仕様書を作って』と言われたけど、何から始めればいいか分からない...」 「正常系はわかるけど、異常系ってどこまで考えればいいの？」 「テストケースの抜け漏れが不安...」 私も新人時代、仕様書を読んでも「どうやってテストケースに落とし込むの？」と途方に暮れていました。 この記事では、 仕様書からテストケースを作る思考プロセス を、ステップバイステップで解説します。 記事の最後に 印刷して使えるチートシート も用意しました！ 対象読者 単体テスト仕様書を初めて作成する新人エンジニア テストケースの抜け漏れが不安な方 仕様書からテストケースへの変換方法を知りたい方 この記事でわかること ✅ 仕様書の効率的な読み方 ✅ テストケースの抽出方法 ✅ 正常系・異常系・境界値の考え方 ✅ 実務で使える思考プロセス ✅ すぐ使えるチートシート 目次 仕様書からテストを作る全体の流れ ステップ1：仕様書を3色でマーク ステップ2：テスト観点を洗い出す ステップ3：正常系テストを作る ステップ4：異常系テストを作る ステップ5：境界値テストを作る 実践例：ログイン機能のテストケース作成 チートシート：机に貼っておこう よくある質問 まとめ 仕様書からテストを作る全体の流れ 基本的な流れ（30分〜1時間） 1. 仕様書を読む（3色でマーク） ← 5分 2. テスト観点を洗い出す ← 5分 3. 正常系テストを作る ← 10分 4. 異常系テストを作る ← 10分 5. 境界値テストを作る ← 5分 6. レビュー＆修正 ← 5分 ポイント ：一度に完璧を目指さない。まず「骨格」を作って、後で肉付けする。 ステップ1：仕様書を3色でマーク なぜマーキングするのか？ 仕様書を読むだけでは、テストケースに必要な情報が頭に残りません。 3色でマーキング すると、テストケースが自然と見えてきます。 マーキングのルール 色 マークする内容 例 🟡 黄色 入力値・条件 「ユーザーIDは6〜50文字」 🔵 青色 期待結果・挙動 「ホーム画面に遷移する」 🔴 赤色 エラー条件・制約 「空白の場合はエラー表示」 実例：ログイン機能の仕様書 【機能名】ログイン機能 【概要】 ユーザーがユーザーIDとパスワードを入力してログインする。 【仕様】 1. ユーザーIDは6〜50文字の英数字とする。🟡 2. パスワードは8〜20文字の英数字記号とする。🟡 3. 正しいID・パスワードが入力された場合、ホーム画面に遷移する。🔵 4. IDまたはパスワードが間違っている場合、「ID/パスワードが正しくありません」と表示する。🔴 5. IDまたはパスワードが空白の場合、「IDを入力してください」または「パスワードを入力してください」と表示する。🔴 6. 連続3回ログイン失敗した場合、アカウントをロックする。🔴 マーキング後の気づき ： 🟡 黄色：入力値の範囲が2つある（ID：6〜50文字、PW：8〜20文字） 🔵 青色：成功時の挙動が1つ（ホーム画面遷移） 🔴 赤色：エラーパターンが3つ（誤入力、空白、連続失敗） ここから何がわかる？ → 最低でも 6つのテストケース が必要（正常1 + 異常3 + 境界値2） ステップ2：テスト観点を洗い出す テスト観点とは？ 「 何をテストするか 」を簡潔にまとめたもの。 洗い出し方法 マーキングした仕様書から、以下の表を埋める： 番号 テスト観点 分類 優先度 1 正しいID・PWでログイン成功 正常系 高 2 誤ったPWでログイン失敗 異常系 高 3 ID空白でエラー表示 異常系 高 4 PW空白でエラー表示 異常系 高 5 連続3回失敗でアカウントロック 異常系 中 6 ID最小文字数（6文字）で成功 境界値 中 7 ID最大文字数（50文字）で成功 境界値 中 8 ID文字数不足（5文字）でエラー 境界値 低 テスト観点の優先度 高 ：必ず実施（基本フロー、よく使う機能） 中 ：できれば実施（境界値、頻度低いエラー） 低 ：余裕があれば実施（レアケース） ステップ3：正常系テストを作る 正常系とは？ 「仕様通りに動く」ことを確認するテスト 正常系の考え方 Q: 「この機能、どう使うのが正解？」 A: それが正常系 正常系テストケースの作り方 テンプレート ： ■ テストID: XXX-001 ■ テスト項目: ○○機能の正常系 ■ テスト観点: 正常系 ■ 前提条件: （あれば記載） ■ 入力値: 正しい値 ■ 操作手順: 1. ××を入力 2. ボタンを押下 ■ 期待結果: ✅ 仕様書に書かれた挙動 例：ログイン機能の正常系 ■ テストID: LOGIN-001 ■ テスト項目: 正しいID・PWでログイン ■ テスト観点: 正常系 ■ 前提条件: ユーザー登録済み ■ 入力値: - ユーザーID: [email protected] - パスワード: Test1234! ■ 操作手順: 1. ユーザーIDを入力 2. パスワードを入力 3. ログインボタンを押下 ■ 期待結果: ✅ ホーム画面に遷移すること ✅ ヘッダーにユーザー名が表示されること ポイント ： 期待結果は 具体的 に書く（「ログインできる」ではなく「ホーム画面に遷移」） 複数の確認項目があれば箇条書きで列挙 ステップ4：異常系テストを作る 異常系とは？ 「エラーが正しく処理される」ことを確認するテスト 異常系の考え方 Q: 「この機能、どう使うと失敗する？」 A: それが異常系 異常系を見つける魔法の質問5つ 質問 異常系のパターン 1. 空白だったら？ 必須項目が未入力 2. 間違った値だったら？ 不正な形式、存在しないデータ 3. 権限がなかったら？ アクセス制御、認証エラー 4. 同時にやったら？ 排他制御、二重送信 5. 何度もやったら？ 連続実行、リトライ上限 例：ログイン機能の異常系 ■ テストID: LOGIN-002 ■ テスト項目: 誤ったPWでログイン失敗 ■ テスト観点: 異常系 ■ 前提条件: ユーザー登録済み ■ 入力値: - ユーザーID: [email protected]（正しい） - パスワード: WrongPassword（誤り） ■ 操作手順: 1. 正しいユーザーIDを入力 2. 誤ったパスワードを入力 3. ログインボタンを押下 ■ 期待結果: ✅ ログイン画面のまま ✅ エラーメッセージ「ID/パスワードが正しくありません」が表示されること ✅ 入力値はクリアされること（セキュリティ） ■ テストID: LOGIN-003 ■ テスト項目: ID空白でエラー表示 ■ テスト観点: 異常系 ■ 前提条件: なし ■ 入力値: - ユーザーID: （空白） - パスワード: Test1234! ■ 操作手順: 1. ユーザーIDを空白のまま 2. パスワードを入力 3. ログインボタンを押下 ■ 期待結果: ✅ エラーメッセージ「IDを入力してください」が表示されること ✅ ログイン処理が実行されないこと ポイント ： エラーメッセージの文言も 具体的 に記載 セキュリティ要件（入力値クリア、情報漏洩防止など）も確認 ステップ5：境界値テストを作る 境界値とは？ 「範囲の端っこ」をテストする なぜ？ → バグは境界で起きやすいから！ 境界値分析の公式 範囲が「X〜Y」の場合： 【テストすべき値】 ・X（最小値） ・Y（最大値） ・X-1（最小値の1つ下）← エラーになるはず ・Y+1（最大値の1つ上）← エラーになるはず 例：ユーザーID（6〜50文字）の境界値 値 文字数 期待結果 テスト観点 abcde 5文字 ❌ エラー 境界値（最小-1） abcdef 6文字 ✅ 成功 境界値（最小） a×49回+b 50文字 ✅ 成功 境界値（最大） a×50回+b 51文字 ❌ エラー 境界値（最大+1） 例：ログイン機能の境界値テスト ■ テストID: LOGIN-004 ■ テスト項目: ID最小文字数（6文字）でログイン ■ テスト観点: 境界値 ■ 前提条件: 6文字のユーザーID（abcdef）で登録済み ■ 入力値: - ユーザーID: abcdef（6文字） - パスワード: Test1234! ■ 操作手順: 1. 6文字のユーザーIDを入力 2. パスワードを入力 3. ログインボタンを押下 ■ 期待結果: ✅ ホーム画面に遷移すること ■ テストID: LOGIN-005 ■ テスト項目: ID文字数不足（5文字）でエラー ■ テスト観点: 境界値 ■ 前提条件: なし ■ 入力値: - ユーザーID: abcde（5文字） - パスワード: Test1234! ■ 操作手順: 1. 5文字のユーザーIDを入力 2. パスワードを入力 3. ログインボタンを押下 ■ 期待結果: ✅ エラーメッセージ「IDは6文字以上で入力してください」が表示されること ポイント ： 境界値は 必ず4パターン テストする（最小、最大、最小-1、最大+1） 日付、数値、文字列など、範囲があるものは全て境界値テスト対象 実践例：ログイン機能のテストケース作成 仕様書（再掲） 【機能名】ログイン機能 【仕様】 1. ユーザーIDは6〜50文字の英数字とする。 2. パスワードは8〜20文字の英数字記号とする。 3. 正しいID・パスワードが入力された場合、ホーム画面に遷移する。 4. IDまたはパスワードが間違っている場合、「ID/パスワードが正しくありません」と表示する。 5. IDまたはパスワードが空白の場合、「IDを入力してください」または「パスワードを入力してください」と表示する。 6. 連続3回ログイン失敗した場合、アカウントをロックする。 テストケース一覧（全15ケース） 正常系（2ケース） ID テスト項目 観点 入力値 期待結果 LOGIN-001 正しいID・PWでログイン 正常系 ID: [email protected] PW: Test1234! ホーム画面に遷移 LOGIN-002 ログイン後のセッション維持 正常系 ログイン後、別ページに遷移 セッションが維持される 異常系（7ケース） ID テスト項目 観点 入力値 期待結果 LOGIN-003 誤ったPWでログイン失敗 異常系 ID: 正しい PW: WrongPW エラー「ID/パスワードが正しくありません」 LOGIN-004 誤ったIDでログイン失敗 異常系 ID: wrongid PW: 正しい エラー「ID/パスワードが正しくありません」 LOGIN-005 ID空白でエラー表示 異常系 ID: 空白 PW: Test1234! エラー「IDを入力してください」 LOGIN-006 PW空白でエラー表示 異常系 ID: testuser PW: 空白 エラー「パスワードを入力してください」 LOGIN-007 両方空白でエラー表示 異常系 ID: 空白 PW: 空白 エラー「IDを入力してください」 LOGIN-008 連続3回失敗でロック 異常系 誤ったPWで3回連続 アカウントロック、エラー表示 LOGIN-009 ロック後のログイン試行 異常系 ロック中に正しいID・PW エラー「アカウントがロックされています」 境界値（6ケース） ID テスト項目 観点 入力値 期待結果 LOGIN-010 ID最小文字数（6文字） 境界値 ID: abcdef（6文字） PW: Test1234! ログイン成功 LOGIN-011 ID最大文字数（50文字） 境界値 ID: a×50（50文字） PW: Test1234! ログイン成功 LOGIN-012 ID文字数不足（5文字） 境界値 ID: abcde（5文字） PW: Test1234! エラー「IDは6文字以上」 LOGIN-013 ID文字数超過（51文字） 境界値 ID: a×51（51文字） PW: Test1234! エラー「IDは50文字以内」 LOGIN-014 PW最小文字数（8文字） 境界値 ID: testuser PW: Test123!（8文字） ログイン成功 LOGIN-015 PW最大文字数（20文字） 境界値 ID: testuser PW: Test1234567890!@（20文字） ログイン成功 テストケース作成の所要時間 仕様書マーキング：5分 テスト観点洗い出し：5分 正常系作成（2ケース）：5分 異常系作成（7ケース）：15分 境界値作成（6ケース）：10分 合計：40分 チートシート：机に貼っておこう ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ 仕様からテストケースを作る思考プロセス ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ 【ステップ1】仕様書を3色でマーク 🟡 黄色 = 入力値・条件 🔵 青色 = 期待結果・挙動 🔴 赤色 = エラー条件・制約 【ステップ2】テスト観点を洗い出す □ 正常系：仕様通りに動くか？ □ 異常系：エラーが正しく処理されるか？ □ 境界値：範囲の端っこで動くか？ 【ステップ3】正常系を作る Q: この機能、どう使うのが正解？ → それが正常系 【ステップ4】異常系を作る（魔法の質問5つ） 1. 空白だったら？ 2. 間違った値だったら？ 3. 権限がなかったら？ 4. 同時にやったら？ 5. 何度もやったら？ 【ステップ5】境界値を作る 範囲が「X〜Y」なら： ✓ X（最小値） ✓ Y（最大値） ✓ X-1（最小値の1つ下） ✓ Y+1（最大値の1つ上） ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【テストケースの優先度】 高：基本フロー、よく使う機能 中：境界値、頻度低いエラー 低：レアケース 【テストケースのテンプレート】 ■ テストID: XXX-001 ■ テスト項目: ○○機能の×× ■ テスト観点: 正常系/異常系/境界値 ■ 前提条件: （あれば） ■ 入力値: 具体的な値 ■ 操作手順: 1. ×× 2. △△ ■ 期待結果: ✅ 具体的な挙動 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【よくある見落とし】 ⚠ エラーメッセージの文言確認 ⚠ セキュリティ要件（入力値クリアなど） ⚠ 複数項目の組み合わせパターン ⚠ 日付の境界値（月末、うるう年など） ⚠ 権限による表示制御 ⚠ 排他制御、同時実行 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【時短テクニック】 ✓ テンプレート行をコピペ ✓ 結合セルで共通項目を使い回し ✓ プルダウンで入力ミス防止 ✓ フィルターで進捗管理 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ よくある質問 Q1: 正常系と異常系、どっちから作るべき？ A: 正常系から作るのがおすすめ 理由： 正常系を作ると「基本フロー」が見える その基本フローの「逆パターン」が異常系になる 異常系だけ作ると、正常系を見落とすことがある Q2: テストケースはどこまで細かく作ればいい？ A: プロジェクトの方針による 目安： 超重要機能（決済、個人情報など） : 100ケース以上も普通 通常機能 : 20〜50ケース 小さな機能 : 5〜10ケース 迷ったら、先輩やPMに「このレベルで大丈夫ですか？」と確認する。 Q3: 境界値テストって全部やらないとダメ？ A: 優先度をつけて、時間があればやる 優先順位： 最小値・最大値 （必須） 最小-1、最大+1 （できれば） その他の境界値（余裕があれば） Q4: 仕様書に書いてないことはどうテストする？ A: 仕様書に書いてないことは「仕様確認」が必要 例： 「連続3回失敗でロック」→ ロック解除方法は？ 「エラー表示」→ 表示位置は？ 色は？ やること ： 不明点をリストアップ 仕様書作成者（設計者）に質問 回答をもらってからテストケース作成 Q5: テストケースが多すぎて実施時間が足りない... A: 優先度をつけて、高優先度から実施 対策： テストケースに優先度（高・中・低）をつける まず「高」を全部実施 時間があれば「中」「低」を実施 全部実施できなくても、優先度が明確なら問題ない まとめ 仕様からテストを作る5ステップ ステップ やること 所要時間 1 仕様書を3色でマーク 5分 2 テスト観点を洗い出す 5分 3 正常系テストを作る 10分 4 異常系テストを作る 10分 5 境界値テストを作る 5分 合計：35分 （慣れたら20分） 重要なポイント 仕様書をしっかり読む マーキングすると読み飛ばしが減る 不明点は必ず確認する 正常系→異常系→境界値の順で作る いきなり完璧を目指さない まず骨格を作ってから肉付け テストケースは具体的に書く 「ログインできる」ではなく「ホーム画面に遷移する」 第三者が読んで理解できるレベルで 優先度をつける 全部やろうとしない 重要なテストから実施 テンプレートを活用 コピペで効率化 共通項目は使い回し 次のステップ このチートシートを印刷して机に貼る 1つの機能でテストケースを作ってみる 先輩にレビューしてもらう フィードバックを受けてテンプレート改善 次の機能でもう一度試す 最初は時間がかかりますが、慣れたら30分で30ケース作れるようになります！ 最後まで読んでいただき、ありがとうございました！ 「仕様書を読んでもテストケースが思い浮かばない...」という悩みは、 正しい 思考プロセス を知れば解決します。 この記事が、皆さんの単体テスト作成の助けになれば幸いです。 この記事が役に立ったら、LGTM（いいね）をお願いします！ 😊 チートシート印刷用 仕様→テストケース作成チートシート 印刷して机に貼ろう！ 📝 5ステップ（所要時間：35分） ステップ1：仕様書を3色でマーク（5分） 🟡 黄色 = 入力値・条件 🔵 青色 = 期待結果・挙動 🔴 赤色 = エラー条件・制約 ステップ2：テスト観点を洗い出す（5分） □ 正常系：仕様通りに動くか？ □ 異常系：エラーが正しく処理されるか？ □ 境界値：範囲の端っこで動くか？ ステップ3：正常系を作る（10分） Q: この機能、どう使うのが正解？ → それが正常系 ステップ4：異常系を作る（10分） 魔法の質問5つ 1. 空白だったら？ → 必須項目未入力 2. 間違った値だったら？ → 不正な形式、存在しないデータ 3. 権限がなかったら？ → アクセス制御、認証エラー 4. 同時にやったら？ → 排他制御、二重送信 5. 何度もやったら？ → 連続実行、リトライ上限 ステップ5：境界値を作る（5分） 範囲が「X〜Y」なら、4パターンテスト： ✓ X （最小値） → 成功するはず ✓ Y （最大値） → 成功するはず ✓ X-1 （最小値の1つ下） → エラーになるはず ✓ Y+1 （最大値の1つ上） → エラーになるはず ⚙️ テストケースのテンプレート ■ テストID: XXX-001 ■ テスト項目: ○○機能の×× ■ テスト観点: 正常系 / 異常系 / 境界値 ■ 前提条件: （あれば記載） ■ 入力値: - 項目1: 値1 - 項目2: 値2 ■ 操作手順: 1. ××を入力 2. ボタンを押下 ■ 期待結果: ✅ 具体的な挙動を記載 ✅ 複数ある場合は箇条書き 🎯 優先度の決め方 優先度 対象 実施タイミング 高 基本フロー、よく使う機能 必ず実施 中 境界値、頻度低いエラー できれば実施 低 レアケース 余裕があれば ⚠️ よくある見落とし □ エラーメッセージの文言確認 □ セキュリティ要件（入力値クリア、情報漏洩防止） □ 複数項目の組み合わせパターン □ 日付の境界値（月末、うるう年、2月29日） □ 権限による表示制御 □ 排他制御、同時実行 □ 特殊文字（<script>、SQL注入など） □ 文字コード（絵文字、全角半角） 💡 時短テクニック ✓ テンプレート行をコピペ ✓ 結合セルで共通項目を使い回し ✓ プルダウンで入力ミス防止 ✓ フィルターで進捗管理 ✓ 似た機能はシートごとコピー 📊 テストケース数の目安 機能の重要度 テストケース数 超重要（決済、個人情報） 100ケース以上 通常機能 20〜50ケース 小さな機能 5〜10ケース 🔍 境界値テストの対象 【対象になるもの】 ✓ 文字数（6〜50文字など） ✓ 数値範囲（0〜100など） ✓ 日付範囲（2024/01/01〜2024/12/31など） ✓ ファイルサイズ（1MB以下など） ✓ 件数（最大1000件など） 【境界値の例】 ・文字数6〜50文字 → 5文字（NG）、6文字（OK）、50文字（OK）、51文字（NG） ・数値0〜100 → -1（NG）、0（OK）、100（OK）、101（NG） 🛠️ 実践例：ログイン機能 仕様 ・ユーザーIDは6〜50文字 ・パスワードは8〜20文字 ・正しいID・PWでホーム画面遷移 ・誤入力時エラー表示 ・連続3回失敗でロック テストケース（15ケース） 【正常系：2ケース】 1. 正しいID・PWでログイン成功 2. ログイン後のセッション維持 【異常系：7ケース】 3. 誤ったPWでログイン失敗 4. 誤ったIDでログイン失敗 5. ID空白でエラー 6. PW空白でエラー 7. 両方空白でエラー 8. 連続3回失敗でロック 9. ロック後のログイン試行 【境界値：6ケース】 10. ID最小文字数（6文字）で成功 11. ID最大文字数（50文字）で成功 12. ID文字数不足（5文字）でエラー 13. ID文字数超過（51文字）でエラー 14. PW最小文字数（8文字）で成功 15. PW最大文字数（20文字）で成功 📝 仕様書のチェックリスト 仕様書を読む時、以下を確認： □ 入力項目は全て把握したか？ □ 入力項目ごとの制約（文字数、形式）は？ □ 正常時の挙動は明確か？ □ エラー時の挙動は明確か？ □ エラーメッセージは指定されているか？ □ 前提条件（ログイン必要など）は？ □ 権限による違いは？ □ 不明点はリストアップしたか？ 🚀 作業の流れ 1. 仕様書を読む（マーキング） 5分 2. テスト観点を洗い出す 5分 3. 正常系テストケース作成 10分 4. 異常系テストケース作成 10分 5. 境界値テストケース作成 5分 ────────────────────────── 合計 35分 ※慣れたら20分で完了 💬 困った時の質問リスト 【仕様が不明確な時】 → 「○○の場合の挙動は？」と設計者に確認 【テストケースが多すぎる時】 → 優先度をつけて、高優先度から実施 【境界値をどこまでやるか迷う時】 → 最小・最大だけは必須、時間があれば±