「仕様書どおりにテストケースを作ったが、抜けがないか不安だ」
「正常系は確認したが、どこまで異常系を広げればよいか分からない」
テスト観点とは、どのような切り口で品質を確認するかを整理したものです。操作手順を書く前に観点を作ることで、仕様の写しだけでは見つけにくい不具合を検討できます。
ケース数を増やせば品質が上がるとは限りません。重要な業務リスク、変更内容、過去不具合から、どの条件を重点的に確認するかを決める必要があります。
金融システムでは、金額の境界値、権限、処理日、二重操作、タイムアウト、後続処理など、一つの画面から見えないリスクもあります。テスト対象を処理全体で捉えることが重要です。
この記事では、仕様とリスクからテスト観点を作り、ケースへ落とし込む手順を解説します。
テスト観点は「仕様」と「失敗したときのリスク」から作る
仕様書に書かれた条件を確認するだけでなく、誤った結果になったときに何が困るかを考えます。重大なリスクほど、複数の観点や深い確認が必要です。
観点は網羅性を検討するための切り口、テストケースは具体的な条件・操作・期待結果です。両者を分けると、重複と抜けを確認しやすくなります。
| 観点 | 確認内容 | 例 |
|---|---|---|
| 正常系 | 代表的な入力で正しく完了する | 通常金額の振込が完了 |
| 異常系 | 不正・不足・外部エラーを制御する | 必須未入力、DBエラー |
| 境界値 | 条件の境目で判定が正しい | 上限－1、上限、上限＋1 |
| 状態遷移 | 状態と操作の組合せが正しい | 受付済→承認済→送信済 |
| 権限・競合 | 利用者差・同時操作を制御する | 一般／承認者、二重押下 |
| 周辺・後続 | 関連機能へ悪影響がない | 照会、取消、バッチ、連携 |
テスト観点を作る4ステップ
1．変更内容と守りたい品質を整理する
要件、設計変更、障害修正の内容を確認し、「何が正しければ完了か」「何が起きると重大か」を整理します。
たとえば上限チェックの変更なら、判定の正しさだけでなく、エラー時にデータが登録されないこと、メッセージが適切なことも品質条件です。
2．基本の観点で条件を広げる
正常系、異常系、境界値、状態遷移、権限、同時実行、性能、セキュリティなどから、対象に必要な観点を選びます。
すべてを均等に増やすのではなく、変更箇所とリスクが高い部分へ重点を置きます。
- 入力値：最小・最大・空・形式不正
- 状態：処理前・処理中・完了・取消
- 利用者：権限・所属・端末・チャネル
- 時間：日跨ぎ・月末・締め時刻
- 競合：連打・同時更新・再送
- 連携：正常・遅延・エラー・重複
3．処理の前後と横展開を確認する
変更した機能だけでなく、入力元、共通部品、関連画面、後続バッチ、外部連携への影響を確認します。変更箇所のテストとデグレード確認を分けて考えます。
過去の類似不具合やレビュー指摘も観点へ追加します。同じ原因が別機能に潜んでいないかを確認します。
変更：振込上限の判定ロジック 直接確認：上限未満／上限一致／上限超過 周辺確認：入力画面、確認画面、エラーメッセージ 後続確認：取引登録なし、バッチ抽出なし、外部送信なし 横展開：予約振込、定期振込、API受付
4．観点を具体的な条件と期待結果へ落とす
「境界値を確認する」だけでは実施できません。具体的な入力値、事前状態、操作、期待結果へ落とします。期待結果は画面だけでなく、DB、ログ、外部連携も必要に応じて定義します。
観点とケースの対応表を作ると、どの観点が未実施かを確認できます。
テスト観点表のテンプレート
観点、リスク、具体条件、確認先を一つの表へまとめます。
【対象変更】 機能・要件： 守りたい品質： 重大リスク： 【観点一覧】 観点／リスク／具体条件／期待結果／確認先／優先度／ケースNo. 確認先：画面／DB／ログ／外部連携／帳票 優先度：高／中／低 【横展開】 共通部品： 類似機能： 過去不具合：
観点表はケース作成前のレビューにも使えます。手順が増える前に抜けを議論できるため、修正コストを抑えられます。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| 仕様の文章をケース化するだけ | 境界や失敗時のリスクを見落とす | 品質リスクから観点を追加する |
| 正常系を細かく増やす | 異常系・状態遷移が不足する | 観点ごとの配分を確認する |
| 変更機能だけを見る | 共通部品や後続のデグレードを見逃す | 前後・横展開を確認する |
若手SE向けチェックリスト
- 変更内容と受入条件を確認した
- 失敗時の業務・システムリスクを整理した
- 正常系・異常系・境界値を検討した
- 状態遷移・権限・同時実行を検討した
- 周辺機能・後続処理・外部連携を確認した
- 過去不具合と類似機能を横展開した
- 観点を具体条件と期待結果へ落とした
まとめ：テスト観点は重要なリスクを見逃さないための地図
テスト観点は、ケース数を増やすためではなく、重要な品質リスクを適切な条件で確認するために作ります。
最初から完璧な観点表を作れなくても、設計レビューや不具合分析で得た気付きを追加し、チームの知財として育てていきましょう。
- 仕様と失敗時のリスクから考える
- 基本観点で条件を広げる
- 前後・横展開を具体的なケースへ落とす
コメント