はじめに
テストケースを作るときに、「これで全部チェックできてるのかな…？」「なんか見落としてる気がする…」と不安になることがよくありました。
この記事では、私がそういった不安や悩みから解放されたきっかけとなった、
「テスト観点の出し方」と「テストケースの作り方」についてまとめています。
備忘録的でもありますが、同じように悩んでいる方のヒントになれば嬉しいです。
作成しているもの
テストをする際には、以下の2つを セットで作成 するようにしています。
この順序を守るだけでも、自然と網羅性の高いテストができるようになります。
- テスト観点
- テストケース
テスト観点（観点出し）
具体的なテストケースを作る前に、以下の点を意識しながら 観点出し を行います。
- 方向性を間違えていないか（目線・要件とのズレがないか）
- 抜け漏れがないか（MECE：漏れなく、ダブりなく）
- 全体のボリューム感（テスト工数の見積もりにもつながる）
観点出しのための一覧は以下のように作成しています：
| 画面・機能 | 大項目 | 中項目 | 小項目 | 備考 |
|---|---|---|---|---|
| 画面A | バリデーション | 項目a | 入力なし | |
| 画面A | 項目b | 英数字以外 | ||
| 画面B | テーブル更新 | column1 | ○○に更新 | |
| 画面B | column2 | ○○に更新 |
💡 ポイント
- ツリー構造で「広く・深く」掘り下げると、抜け漏れが起きにくいです。
- この観点一覧が テストケースのベース になります。
テストケース
テスト観点から、実際の検証ステップに落とし込む フェーズです。
観点で出したものをもとに、1ケースずつ具体化していきます。
| 項目名 | 説明 |
|---|---|
| No. | ユニークな番号 |
| 画面・機能 | テスト対象の画面・機能名 |
| 大項目 | 一番大きく分類可能な要素（例：バリデーション、DB更新など） |
| 中項目 | 大項目をさらに細かくした分類 |
| 小項目 | 中項目をより詳細に分けたもの |
| 確認手順 | どうやって確認するのか。使用データや操作手順などを記載 |
| 期待値 | 得られるべき結果。「○○が表示される」「DBに○○が登録される」など |
| 結果 | 〇（成功）、×（失敗）、-（対象外） |
| 試験日 | 実施日 |
| 担当者 | 実施担当者 |
| 備考 | その他、特記事項など |
補足：意識していること
以下のような視点も意識すると、より漏れの少ない設計が可能 になります。
- 異常系（エラーパターン）も忘れずにカバーする
- テスト観点と要件定義の照らし合わせ
- 影響範囲の棚卸し（他画面やバッチ処理など）
- 他者レビューのタイミングを意識する（早い段階でレビューをもらうことで大きな修正を防げる）
おわりに
テストケース作成は「ただの作業」になりがちですが、
仕様理解やリスク管理の観点からも非常に重要なフェーズ です。
自分なりの型を持っておくと、スピード・精度の両方が上がるので、
ぜひ自分なりのやり方を磨いていくヒントにしていただければと思います。