テスト観点ってなに？はもう終わり。完全理解マンへの道
はじめに
ソフトウェアテストを行う際によく聞く「テスト観点」という言葉。しかし、その意味や「テスト項目」との違いについて曖昧な理解のままテストを行っている方も多いのではないでしょうか。この記事では、テスト観点の基本概念について整理し、実際のテスト設計にどう活用するかを解説します。
テスト観点とは何か
テスト観点とは、ソフトウェアの「どの部分」を「どのような」視点でテストすれば品質を確保できるかという着眼点のことです。
大きなシステムには多くの要素が含まれており、すべてを網羅的にテストすることは現実的ではありません。そこで「システムのどの点を観てテストするか」を明確にするのが観点の役割です。
観点の「種類」と「深さ」
テスト観点を理解する上で重要なのは、観点には種類と深さの2つの軸があることです。
観点の種類
観点の種類とは、システムのどの側面に注目するかを表します。代表的な観点の種類には以下があります：
- 機能観点：アプリケーションが提供する機能に注目
- アクセシビリティ観点：障害者や高齢者でも使いやすいかに注目
- セキュリティ観点：システムの安全性に注目
- パフォーマンス観点：処理速度や応答性に注目
観点の深さ
同じ種類の観点でも、抽象度によって深さが変わります。
例えば機能観点の場合：
抽象的な観点
- 「認証機能の品質を担保する」
具体的な観点
- 「未ログインの状態であれば、ログインができること」
- 「ログイン済みであれば登録できること」
- 「ゲストログインでも閲覧できること」
具体的な観点は、抽象的な機能をより詳細な「点」で見ているということになります。
この２軸の存在を知らないと、これは観点？こっちも観点？どれが観点だっけ？となります。振り返ってみれば全部観点だったりするかもしれません。
観点とテスト項目(テストケース)の違い
観点とテスト項目（テストケース）は混同されがちですが、明確な違いがあります。
観点は「結果」に注目
観点は「ログイン済みであれば登録できること」のように、システムがどうあるべきかという結果に注目します。また「未ログインで登録できるのはシステムとして問題がある」の逆を確認する行為です。逆を確認する(観点を満たす)ことができれば品質が担保されたと言えます。これが観点の力といえます。
テスト項目は「手順」を具体化
一方、テスト項目は観点で示された結果を確認するための前提条件と操作手順を具体化したものです。
観点の例：
「ログイン済みであれば登録できること」
対応するテスト項目の例：
- 前提条件：ユーザーAでログイン済み
- 操作手順：1. 登録画面を開く → 2. 必要項目を入力 → 3. 登録ボタンをクリック
- 期待結果：登録が完了し、完了メッセージが表示される
以上のようにテスト項目によって観点が満たされていることが確認されることがわかると思います。また期待結果と観点がほぼ一致することになります。これは前述した通り観点を満たしていることを確認するためのテスト項目であることを考えれば納得ですよね。
このように観点がテスト項目に含まれているので、観点とテスト項目がごっちゃになっているように感じてしまいます。（私はそうでした。。。）
まとめ
テスト観点は品質確保のための「着眼点」であり、システムの品質基準を示すものです。一方、テスト項目はその品質基準を確認するための具体的な手順です。
この違いを理解することで、より効果的なテスト設計が可能になります。まず観点を整理してシステムのどの部分の品質を確保したいかを明確にし、その後で具体的なテスト項目に落とし込むというプロセスを意識してみてください。
補足
観点は結果だけじゃない？
観点は結果です。と言い切りましたが、これは話を単純化するためでした。より踏み込んで話します。ここまで読んでいる方であれば混乱せずに読めると思います。
実際には、観点は必ずしも「結果」に限定されません。品質を確認する視点として、以下のようなものも含まれます。
-
入力条件に着目する観点
どのような入力でテストするかを意識します。例として、ユーザーが未入力で送信した場合や、最大文字数を超える入力を行った場合などがあります。 -
処理の流れに着目する観点
システムの処理が正しい順序で実行されるかを確認します。例：注文処理→支払い処理→在庫更新 の順番が正しいかどうか。 -
例外的なシナリオに着目する観点
エラーや特殊条件での挙動を確認します。例：ネットワーク切断時、サーバーエラー時、想定外のデータが入力された場合などです。
このように、観点は「結果を見るだけ」でなく、どの入力や状況で、どのような処理を経て結果に至るかを意識してテストする際の考え方全体を含みます。
観点例として上げた「ログイン済みであれば登録できること」にも実はログイン済みという条件がありました。またログインしたあとに登録する流れという点を見ていたとも言えます。
記事で紹介した「機能観点の深さ」の例は結果に近いものですが、このように視点を広げるとより実践的なテスト設計が可能になります。
テスト項目とテストケースを分けて考えてみる
今回同じものとして記述しましたが、分ける考え方もありそうです。
例えば以下です
- 観点（抽象）：ログイン機能が正常に動作すること
- 観点（具体）：未ログイン状態からログインできること
- テスト項目：正しいID/PWを入力したらログイン成功すること
- テストケース：ユーザーID「test」、PW「1234」でログイン操作し、成功画面に遷移すること
- テスト項目：正しいID/PWを入力したらログイン成功すること
- 観点（具体）：未ログイン状態からログインできること
上記のようにテスト項目は観点(具体)を満たす働きをします。１つの観点に対して複数のテスト項目が存在することもあるでしょう。説明では話を単純化するためにテスト観点とテスト項目の２つに絞りましたが、より分解して構造化することができることを理解しておくと良いかもしれません。
Discussion