仕様書を読んだのに、何をテストすればよいか分からない。これは初心者SEが実務でつまずきやすいポイントです。
仕様書には処理内容が書かれていても、テスト観点がそのまま書かれているとは限りません。画面の動きや入力項目は分かっても、どの条件を確認すべきか、どこまで例外系を見るべきか、既存機能への影響をどう考えるべきかで迷うことがあります。
私自身、現場でテスト設計やレビューに関わる中で、テスト観点を出せる人は「仕様書を読む力」だけでなく「仕様の裏側にある条件を疑う力」を持っていると感じています。
この記事では、仕様書を読んでもテスト観点が出せないときに、現役SEとして私が実務で見ているポイントを整理します。
この記事でわかること
- 仕様書からテスト観点を出す基本の考え方
- 初心者が見落としやすい条件分岐と例外系
- 現役SEが実務で確認している判断基準
- AIを使ってテスト観点を広げるときの注意点
仕様書は「書かれていること」だけを読むと足りない
仕様書を読むとき、まず書かれている内容を理解することは大切です。どの画面で、どのボタンを押すと、どの処理が動くのか。これはテストの前提になります。
ただし、実務では書かれていることだけを確認してもテストとして不十分になることがあります。
たとえば、仕様書に「検索条件を入力して検索ボタンを押すと一覧を表示する」と書かれていたとします。この一文からでも、確認すべきことは複数あります。
- 検索条件を何も入力しない場合
- 一部の条件だけ入力した場合
- 該当データが0件の場合
- 検索結果が大量にある場合
- 権限によって表示できるデータが変わる場合
- 削除済みや無効データを含めるかどうか
仕様書に明記されていないから確認しなくてよい、とは限りません。むしろ、書かれていない条件をどう扱うかが実務では重要になります。
AIでテストケースを作る基本的な流れは「AIでテストケースを作る方法」でも解説しています。
失敗例1：正常系だけでテストを作る
初心者が最初にやりがちなのは、正常に操作した場合だけをテストケースにすることです。
たとえば、登録画面なら「必須項目を入力して登録できる」、検索画面なら「条件を入力して検索できる」といったテストです。もちろん正常系は必要ですが、それだけでは不十分です。
実務では、次のような観点も確認します。
- 必須項目が未入力の場合
- 文字数の上限を超えた場合
- 日付の前後関係が不正な場合
- 同じデータを二重登録しようとした場合
- 登録途中でエラーになった場合
- 権限がないユーザーが操作した場合
正常系だけのテストでは、実際の利用時に起きる問題を拾いきれません。仕様書を読むときは、成功する流れだけでなく、失敗する条件も意識する必要があります。
失敗例2：条件分岐を見落とす
仕様書の中で見落としやすいのが条件分岐です。
「ステータスが承認済みの場合のみ表示する」「管理者の場合は編集可能」「過去日付の場合は登録不可」といった条件は、テスト観点に直結します。
条件分岐を見落とすと、特定の状態だけで不具合が発生することがあります。
| 見る観点 | 確認する内容 | 見落としたときのリスク |
|---|---|---|
| ステータス | 未処理、処理中、完了、取消など | 特定ステータスでボタン表示が誤る |
| 権限 | 一般ユーザー、管理者、承認者など | 見えてはいけない操作ができる |
| 日付 | 過去日、当日、未来日、締切後など | 期限後の処理が通ってしまう |
| データ状態 | 有効、無効、削除済み、重複など | 対象外データが表示・更新される |
| 件数 | 0件、1件、上限件数、大量件数 | 表示崩れや処理遅延に気づけない |
仕様書を読むときは、「条件が変わったら結果も変わるか」を意識すると、テスト観点を出しやすくなります。
失敗例3：未決事項をテスト対象にしてしまう
仕様書の中には、まだ決まっていない内容が混ざっていることがあります。
たとえば「通知方法はメールを想定」「エラー時の文言は別途確認」「権限ごとの表示範囲は調整中」といった表現です。これらを確定仕様としてテストケースにしてしまうと、後から手戻りになります。
テスト観点を作る前に、私は次のように分類します。
- 決定済みの仕様
- 未決事項
- 仮置きの仕様
- 業務担当者の確認が必要な仕様
- 開発側で判断してはいけない仕様
未決事項がある場合は、テストケースを作る前に確認するか、仮の前提として明記しておく必要があります。
要件や前提の整理については「AIに質問する前に整理すべき要件」でもまとめています。
テスト観点を出すときの確認順序
私が仕様書からテスト観点を出すときは、次の順番で確認します。
- 対象機能の目的を確認する
- 利用者と権限を確認する
- 正常系の流れを確認する
- 入力値の制約を確認する
- 条件分岐を洗い出す
- 例外系を確認する
- 既存機能への影響を確認する
- 未決事項を分ける
- テストデータの状態を考える
この順番で見ると、いきなり細かいテストケースを書き始めるよりも抜け漏れが少なくなります。
既存機能への影響も見る
新しい機能のテストを考えるとき、対象機能だけを見ていると不十分な場合があります。
実務では、同じデータを使っている別画面、バッチ処理、帳票、外部連携にも影響が出ることがあります。
- 同じテーブルを参照する画面はないか
- 更新したデータを使うバッチはないか
- 帳票やCSV出力に影響しないか
- 外部システムへ連携する項目は変わらないか
- 既存の権限設定と矛盾しないか
設計書レビューでも、この影響範囲はよく見られます。関連する考え方は「設計書レビューで指摘されやすいポイント」でも整理しています。
AIを使うなら観点の広げ方に使う
AIは、テスト観点を広げる用途には向いています。
ただし、仕様書をそのまま貼り付けて「テストケースを作って」と依頼するだけだと、一般的な観点に寄りやすくなります。
実務で使うなら、次のように聞く方が効果的です。
以下の仕様について、正常系、入力チェック、権限、ステータス、例外系、既存機能への影響に分けてテスト観点を出してください。未決事項や確認すべき前提があれば、テストケースとは分けて指摘してください。
このように分類を指定すると、AIの回答をレビューしやすくなります。最終的には、人が仕様と照らし合わせて採用する観点を判断する必要があります。
まとめ：テスト観点は仕様の裏側から出す
仕様書を読んでもテスト観点が出せないときは、書かれている操作だけを追っている可能性があります。
実務では、正常系だけでなく、条件分岐、例外系、権限、データ状態、既存機能への影響、未決事項を確認する必要があります。
テスト観点を出す力は、単にテストケースを書く力ではありません。仕様を読み、前提を疑い、どこで問題が起きるかを考える力です。
AIを使う場合も、観点を広げる補助として使い、最終判断は人が行う。この使い方ができると、初心者でも実務に近いテスト設計がしやすくなります。
