1 テストケースの概要
1.1 定義と役割
テストケースとは、ソフトウェアやシステムの振る舞いが仕様や合意された基準どおりであることを確認するために用意される検証手順のまとまりである。単なる「入力例」ではなく、前提条件、入力、操作手順、そして検証の基準となる期待結果を一組として具体化する点に特徴がある。 テストケースの役割は、品質の説明可能性を高めることにある。実施した手順と判断基準が記録されるため、欠陥の早期発見だけでなく、リリース判断の根拠を関係者間で共有しやすくなる。
1.2 構成要素
1.2.1 事前条件
事前条件は、テストを開始する前に成立していなければならない状態を示す。例として、初期データの内容、認証状態、権限、ネットワーク条件、タイムゾーン、外部依存（外部サービスの到達性やスタブ状態）などが含まれる。 事前条件が欠けると、実行した結果が偶然に左右され、再現性が低下する。逆に、過度に細かい前提を並べると運用負荷が増えるため、必要十分な粒度に調整することが重要である。
1.2.2 入力と操作手順
入力と操作手順は、対象に対してどのようなデータと操作を行うかを定義する部分である。入力は、画面フォームの値、APIリクエストのパラメータ、ファイル内容、ストリームの投入データなど、多様な形で表現される。 操作手順は、単一操作だけでなく、複数ステップの順序や分岐条件（どの結果を得たときに次へ進むか）を明確にする。特にUI系ではクリック順、待機条件、画面遷移の前提がブレやすいため、手順の具体性が結果の安定に直結する。
1.2.3 期待される結果
期待される結果は、合否判定の基準を具体的に示す。表示値、計算結果、状態遷移、レスポンスコード、エラーメッセージ、ログの出力、データの永続化有無など、観測可能な要素で記述する。 期待結果は「正しそう」ではなく、観測点と判定条件を明確にする必要がある。たとえば数値の場合は桁、許容誤差、丸め規則、並び順などを定義し、テスト実行者の解釈を最小化する。
1.3 設計の観点
1.3.1 正常系
正常系は、仕様が想定する適切な入力・操作に対して、正しい応答が得られることを確認する観点である。代表的なユースケースの成功経路を中心に構成し、主要な機能の機能要件を満たしているかを検証する。 正常系の利点は、ユーザ価値に直結することと、失敗時の調査が比較的容易な場合が多い点にある。一方で、正常系だけに偏ると異常時の品質リスクを見落とす可能性が高い。
1.3.2 異常系
異常系は、想定外または失敗を誘発しうる状況において、仕様どおりのエラー処理や復旧挙動が行われることを確認する観点である。例として、必須項目欠落、形式不正、存在しないリソース指定、タイムアウト、同時実行による競合、外部依存の障害などが挙げられる。 異常系の期待結果は、単に「エラーになる」だけでなく、エラーコードやメッセージの内容、ユーザへの案内、ロールバックの有無、再試行の可否などを含むことが多い。これにより、運用時の判断やサポート対応にも役立つ形で品質が説明される。
1.3.3 境界値と例外
境界値は、仕様上の境目（最小・最大・直前・直後）に関連する入力や状態を対象とする。文字数、数値範囲、日付の範囲、ページングの上限、バッファサイズ、並び替えのキー等の境界は、不具合が潜みやすい。 例外は、境界値の近辺だけでなく、仕様が例外扱いする条件（特定の組み合わせでのみ許可される入力、特定の状態でのみ遷移が可能になる操作など）を扱う。境界と例外を組み合わせることで、入力検証漏れや条件分岐の欠落といった典型的な欠陥を検出しやすくなる。
1.4 再現性と品質
再現性とは、同じテストケースを同じ前提のもとで実行したときに、同様の結果が得られる性質である。再現性を高めるには、前提条件の明確化、外部依存の制御、データ整備、タイミング要因の扱い（待機条件やタイムアウト値）などが重要になる。 また、品質の観点では「カバーしている範囲が説明できるか」が問われる。テストケースが要件やリスクに紐づいて設計されていれば、失敗時の影響範囲や残存リスクを見積もりやすい。結果として、テストの価値が単なる回数ではなく、判断材料として定着する。
2 テストケースの設計
2.1 要件からの導出
2.1.1 仕様の読み替え
2.1.1.1 ユースケース／受け入れ基準との対応
要件からテストを導く際は、ユースケースと受け入れ基準をテスト可能な形に読み替える。受け入れ基準は、最終的に観測可能な振る舞いとして表現し直すことが目的となる。たとえば「ログインできる」ではなく、認証成功時のセッション生成、遷移先、保持期間、失敗時のエラーメッセージなどに分解する。 この対応付けができると、テストがどの要件を検証しているかが追跡可能になり、抜け漏れの発見にもつながる。
2.1.2 トレーサビリティ
トレーサビリティは、テストケースと要件（機能要求、非機能要求、受け入れ基準、設計根拠など）の関係を明示する考え方である。要件の変更や優先度変更が起きたときに、影響を受けるテストを把握しやすくなる。 運用上は、テストケースがどの根拠に基づくかを体系的に管理し、関連がないテストを減らすことが望ましい。結果として、テストスイートが「追加しただけ」で膨らむ状態を防ぎやすくなる。
2.2 標準化と命名規則
2.2.1 テストケースの命名
命名規則は、テストケースを一覧したときに内容が瞬時に把握できるようにするためのルールである。典型的には、対象機能、シナリオ、条件、観点（正常・異常、境界など）、期待結果の要点を組み込む。 命名は技術文書にとどまらず、欠陥報告や実行結果の紐づけにも関わる。たとえば失敗時に「何を試して何が問題か」を追える命名体系を持つほど、調査の初動が速くなる。
2.2.2 優先度と重要度
優先度は、実行順や作業の着手順を決めるための指標であり、重要度は品質上の影響度に関連する概念として扱われることが多い。例えば、顧客の主要導線を壊す不具合は重要度が高く、バックオフィスの軽微な差異は重要度が低い、という整理が可能である。 限られた時間では、重要度の高い項目やリスクの高い境界を優先的にカバーする設計が求められる。優先度の決め方を事前に明文化しておくと、判断の属人性を減らせる。
2.3 粒度と粒度調整
2.3.1 汎用化と再利用
汎用化と再利用は、共通の前提や操作を部品として扱い、複数ケースで同じ要素を活用する設計である。事前準備（データ投入、環境設定、認証）や共通のAPI呼び出し、共通の検証手順などは再利用しやすい。 ただし、過度な抽象化は理解の難しさやデバッグの困難さを招く。再利用する単位は、変更頻度と影響範囲を踏まえて決める必要がある。
2.3.2 個別ケースの切り分け
切り分けは、テストの責務を適切に分けて、失敗時に原因追跡がしやすい状態を作ることを指す。例えば一つのケースに複数の独立機能の検証を詰め込むと、失敗原因の特定が難しくなる。 一方で、細かくし過ぎると実行数が膨れ、管理が複雑になる。粒度調整では、観測点の独立性、前提条件の共有度、期待結果の明確さを基準としてバランスを取る。
3 実行と管理
3.1 実行手順の運用
3.1.1 テスト環境の前提
実行環境の前提は、テストが成立する条件を運用側で保証する領域である。バージョン整合（アプリ、ミドルウェア、依存ライブラリ）、設定値、データの初期状態、外部連携のモード（実通信か、模擬か）などが該当する。 環境の違いで結果が変わる場合、原因が製品の欠陥なのか環境差なのかを切り分ける必要がある。そこで、環境情報を可能な範囲で記録し、再現に役立てることが実務上の要点となる。
3.1.2 実行ログと記録
実行ログと記録は、テストの結果とその背景を後から検証可能にするための情報である。合否、実施時刻、実行者、参照したデータセット、失敗時のエラーメッセージ、画面キャプチャやスタックトレースなどを含める。 記録の粒度が適切であれば、同じ失敗の再発確認や、修正後の検証の妥当性が判断しやすい。逆に、ログが不足すると調査が長期化し、テストの価値が下がる。
3.2 合否判定の考え方
3.2.1 期待結果の解釈
合否判定では、期待結果の条件をどのように比較するかが重要になる。数値比較では許容誤差や丸め規則、時刻ではタイムゾーンやフォーマット、文字列では大小文字や正規化の扱いなどが該当する。 また、非決定的要因（並行処理の順序、遅延、通知タイミング）がある領域では、観測可能な状態に対して「最終的に期待される到達点」を判定する方針が有効である。期待の解釈を曖昧にすると、結果が揺れて再現性を損なう。
3.2.2 失敗の切り分け
失敗が発生した場合、単に「失敗した」という事実だけでなく、分類して次の行動につなげる。典型的には、前提不成立、データ準備不備、環境障害、UI操作の手順誤り、実装不具合、仕様不整合などに分ける考え方がある。 分類ができると、修正の優先度や担当領域を迅速に決められる。特に繰り返し同じ箇所で失敗する場合、テスト自体の欠陥（期待の誤りや観測点の不足）と製品の欠陥（実装不具合）を切り分ける視点が欠かせない。
3.3 回帰テストへの組み込み
3.3.1 変更影響の反映
回帰テストは、変更によって既存機能が壊れていないことを確かめる活動である。変更影響を反映するには、トレーサビリティに基づき、影響範囲に関連するテストケースを抽出して実行することが中心になる。 また、変更点が仕様そのものに関わる場合は、期待結果の更新が必要になる。更新の際は、変更理由と受け入れ基準の確認をセットにしないと、実装を正しているのかテストを正しているのか判別できなくなる。
3.3.2 テストスイートの更新
テストスイートの更新は、追加、削除、修正、整理を含む継続的な作業である。新機能に対応する追加はもちろん、既存ケースの冗長化や重複の解消も対象になる。 運用上は、古いテストが「いつでも通るが意味が薄い」状態にならないよう、期待結果が仕様と一致しているか、観測点が有効かを定期的に見直す。これにより、実行時間の肥大化と誤った安心感の両方を抑えられる。
4 テストケースの改善と応用
4.1 欠陥との関係
4.1.1 失敗から得る学び
失敗から得る学びは、欠陥の修正だけでなく、テスト設計の改善にもつなげる視点である。失敗したテストケースを分析し、前提の誤り、入力条件の不足、期待結果の観測不足、または仕様解釈のズレがあったのかを整理する。 学びが蓄積されると、次回以降は同種の欠陥に対してより的確なケースを準備でき、検出までの時間が短縮される。
4.1.2 優先度の見直し
優先度の見直しは、実行結果や障害履歴に基づいてリスク配分を更新する活動である。たとえば特定の境界で繰り返し失敗が起きるなら、その領域のテスト重要度を上げる判断が合理的になる。 見直しの際は、失敗率だけでなく、失敗時の影響範囲、再発しやすさ、修正コストも合わせて評価する。結果として、限られた工数の中で検証効果を最大化しやすくなる。
4.2 カバレッジ指標
4.2.1 コード／機能カバレッジの考え方
カバレッジ指標は、テストが到達した範囲を見える化するための手段である。コードカバレッジでは分岐や命令がどれだけ実行されたかを測り、機能カバレッジでは要件や機能単位の検証状況を捉える。 指標は「高ければ良い」とは限らない。カバレッジが高くても期待結果の検証が弱ければ品質の裏付けにならないため、観測範囲と判定の厳密さをセットで考える必要がある。
4.2.2 観点の不足の検出
観点の不足の検出は、カバレッジの偏りから弱点を特定する作業である。正常系中心で異常系が薄い、境界が網羅されていない、特定の状態遷移が欠落している、といった形で偏りが現れる。 不足が確認できた場合は、既存ケースを増やすだけでなく、欠落している観測点を明確にした追加シナリオを設計することが効果的である。これにより、テストが「広いだけ」の状態から「意味のある追加」へ移行できる。
4.3 自動化と保守性
4.3.1 自動化に向くケース
自動化に向くのは、繰り返し実行される頻度が高いケース、期待結果が機械的に検証しやすいケース、実行手順が安定しているケースである。回帰テストでは特に効果が出やすい。 一方で、画面の細かなレイアウト差や不安定なタイミングが原因で失敗が頻発する領域は、自動化の設計次第でコストが増える。自動化の判断は、保守負荷と検出価値を見比べて行うのが実務的である。
4.3.2 メンテナンス負荷の抑制
メンテナンス負荷の抑制には、テストの可読性と変更耐性の両立が求められる。データ準備を共通化し、UI要素の参照に依存し過ぎない設計（可能な範囲でAPI層の検証を活用する等）を選ぶと、変更時の影響範囲が縮小しやすい。 また、失敗時の診断に必要な情報を標準でログ出力することで、修正のための調査時間も削減できる。結果として、テストスイートが運用に耐える形で成長する。
4.4 実務でのよくある落とし穴
4.4.1 期待結果の曖昧さ
期待結果が曖昧だと、実行者の解釈により合否がぶれ、テストの信頼性が低下する。「表示されるはず」や「正しい形式であること」だけでは判定が困難であるため、観測可能な条件を言語化しておく必要がある。 曖昧さは失敗の再現性にも影響する。結果が揺れると欠陥と運用要因の切り分けが難しくなり、改善サイクルが停滞しやすい。
4.4.2 冗長な手順
冗長な手順は、余計な操作が増えた結果として、実行時間と修正コストが増える状態である。手順が長いほど途中の依存要因が増え、わずかなUI変更や速度変動でも失敗しやすくなる。 改善策として、前提準備と検証部分を分離し、検証に必要な操作だけを残す整理が有効である。短くても意図が明確なケースほど、保守性が高まりやすい。
4.4.3 仕様変更の追随不足
仕様変更の追随不足は、期待結果や前提条件が更新されず、テストが実態とズレることで生じる問題である。結果として、本来正しい実装であるのに失敗として扱われたり、逆に失敗を見逃したりする。 追随を防ぐには、トレーサビリティを活用して影響するケースを特定し、変更内容に基づく改訂を徹底することが重要である。さらに、改訂の根拠を記録しておくと、後日の監査やレビューにも役立つ。