テスト観点とは？具体例・洗い出し方とテスト観点表の作り方を解説

まずは「テスト観点」の定義や役割から説明していきます。

テスト観点の定義や意味、役割

「テスト観点」は、日本のソフトウェアテストの現場で使われる表現で、国内では通じますが、英語由来の技術用語ではありません。JSTQB Foundation Levelシラバスでは、「テスト分析でテストベースを分析し、テスト可能なフィーチャーを識別して、テスト条件を定義・優先順位付けする」としています。

その後、テスト設計の過程でテスト条件をテストケースなどへ具体化します［1］。本記事では、この過程でテスト条件を見つけ、整理するための切り口を「テスト観点」と呼ぶことにします（図表1）。

具体例に戻りましょう。ログイン機能なら、「ログインできるか」だけでは十分ではありません。

• 入力値
• アカウント状態
• 連続失敗
• 権限
• セッション
• 有効期限
• 同時ログイン
• 応答時間
• 監査ログ

などにテスト観点を分けることで、確認すべき条件が見えてきます。 

テスト観点の役割は大きく分けて、抜け漏れを減らすこと、関係者の認識をそろえること、リスクに応じて優先順位を付けること、の三つとなります。

テストケースやチェックリストとの違い

テスト観点、テスト条件、テストケース、チェックリストは役割と粒度が異なります。

ログイン機能を例に図表2に整理します。

図表2：テスト観点・テスト条件・テストケース・チェックリストの違い 

テスト観点からテスト条件を定め、事前条件、入力、期待結果を含むテストケースへ具体化します。チェックリストは、経験や重要事項に基づく確認項目の一覧です。

テスト観点表をレビューする際は、同じ列に異なる粒度の記述が混在していないかを確認します。

例えば、観点欄に「文字数」と「入力可能文字数（上限）を入力する」が並んでいる場合は、確認の切り口と具体的な入力条件が混在しています。観点欄は「文字数」に統一し、「上限数の文字を入力する」は条件欄またはテストケースに分けて記載します。

次に、テスト観点を「対象」「操作」などで整理する考え方や、実務で役立つ代表的なパターン一覧を紹介します。

「対象」「操作」「振る舞い」「条件」「品質」「リスク」で分類する

必要なテスト観点は、対象となるシステムの特性や利用状況、想定されるリスクによって異なります。そのため、既存のテスト観点一覧をそのまま適用するのではなく、対象に合わせて選定・追加する必要があります［1］。 

テスト観点を整理する際は、要件定義書や設計書、業務フローを確認し、確認事項を「対象」「操作」「振る舞い」「条件」などに分けます。

「操作」は、利用者や外部システムがテスト対象に対して行う入力、登録、承認、取消などの働きかけです。

「振る舞い」は、その操作や条件を受けてシステムが示す処理結果や応答であり、計算処理、画面表示、状態遷移、エラー処理などが該当します。

例えば、対象には画面・API・データベース、操作には入力・登録・承認・取消、振る舞いには計算結果・状態遷移・外部連携への応答、条件には利用者の権限・実行時刻・同時実行の有無などが該当します。 

Web業務アプリケーションのテスト観点一覧表・具体例

図表3は、Web業務アプリケーション向けのテスト観点一覧表です。

実際のテスト設計では、この一覧をそのまま使わず、対象業務、システム構成、利用者、想定されるリスクなどに応じて必要な観点を選び、追加したり具体化したりします。

図表3：Web業務アプリケーションの代表的なテスト観点例

観点を選ぶときに抜けやすいのは、複数の条件が重なるような場面です。

こういった場合、複数条件全ての組み合わせを実行するのではなく、プロダクトリスクを踏まえ、故障が業務へ与える影響の大きい組み合わせを優先することで、合理的にテストケースの実行数の絞り込みができるようにしておきます。

テスト観点は、テスト分析をするためのインプットとなるテストベースと、テスト対象のプロダクトリスクを起点に、次の手順で整理します。

1. 参照するテストベースを広げる：要件、設計、運用手順、過去の欠陥も確認します。
2. 業務上の失敗から逆算する：誤請求や権限逸脱から原因をたどります。
3. 対象・操作・振る舞い・条件を分ける：「何に対して」「誰が何をするか」「システムがどう応答するか」「どの条件で」を整理します。
4. テスト技法で選択する：境界値分析、状態遷移テスト、組み合わせテストなどを使います。
5. レビューして優先順位を付ける：テスト対象に対するリスクによる影響度と発生可能性を基に選びます。

単体テスト・結合テスト・システムテストの観点と洗い出し方

単体テストでは何を確認し、結合テストではどこまで確認すべきでしょうか。こうした疑問を整理するには、テストレベルごとの目的を押さえる必要があります。

JSTQB Foundation Levelシラバスでは、コンポーネントテスト、コンポーネント統合テスト、システムテスト、システム統合テスト、受け入れテストの五つを説明しています［1］。

対象範囲や目的が異なるため、図表4のように重視するテスト観点と粒度も変わります。

図表4：テストレベル別に重視するテスト観点例

一般に「結合テスト」と呼ばれる範囲には、コンポーネント間の連携と外部システムとの連携が含まれることがあります。このため観点表では、どの境界を確認するのかを明記します。

ユーザー視点・品質視点・リスク視点を重ねる

テストレベルごとの観点だけでは、実際の利用場面や業務への影響まで十分に捉えきれないことがあります。ユーザー視点では役割や業務の流れ、品質視点では性能効率性、使用性、信頼性、セキュリティなど、プロダクトリスク視点では故障の発生可能性と影響度を確認します。

三つの視点で捉えることにより、確認の範囲は「仕様通りに動くか」だけでなく、「利用者が安全に業務を完了できるか」まで広がるため、仕様の確認だけでは見つけにくい問題も検討しやすくなります。

次に、受発注管理Webシステムの更改を想定した事例を使ってテスト観点の実務例を挙げます。

営業、承認、倉庫の各担当者が利用し、注文は申請、承認、在庫引当、出荷へ遷移します。在庫サービスとはAPIで連携します。

当初のテスト仕様書は入力値と画面遷移を詳しく確認していましたが、単一利用者が1画面を操作する前提が中心でした。そこで観点表に「権限」「注文状態」「操作」「API応答」「操作タイミング」を追加しました。

承認処理中に営業担当が数量を変更し、在庫APIでは引当が完了したものの応答がタイムアウトするケースを検討しました。数量変更、承認処理、APIタイムアウトの各条件は個別にテストされていましたが、同時発生時の更新順序、二重引当の防止、不整合時の復旧方法は未決でした（図表5）。

Zoom

テスト観点表を用いてテスト仕様書をレビューした結果、承認開始後の編集制限、再送時の重複実行防止、監査ログおよび復旧手順を仕様に追加しました。

また、同時操作、APIの応答未受信、再送、復旧後のデータ整合性に関するテストケースを追加し、未決だった処理条件を仕様とテストの両面で明確にしました。

このように実務においてもテスト観点表を用いてテスト仕様をレビューすることで、仕様自体の抜けや漏れの防止にもつなげられます。

テスト観点表は、テストケースを作る前の中間成果物です。

大分類、テスト対象、テスト観点、テスト条件、関連リスク、テストレベル、優先度を記載します（図表6）。

テスト観点には「権限」「状態遷移」のように短く書き、1行に複数の目的を詰め込まないようにします。そして、仕様やリスクへの参照を残し、テストで見つかった欠陥や本番障害をテスト観点表へ戻します。表形式で関係を追いにくい場合は、VSTePのようにツリー形式で整理する方法もあります。 

図表6は、テスト観点表への記入例です（基本項目に絞った簡易例）。

図表6：テスト観点表への記入例（簡易例） 

上記だけではなく、テストベース・根拠、想定テスト技法、レビュー状況も記録して実務で使用できる、テスト観点表のテンプレートを付録として用意しました。

以下からダウンロードいただき、実際に用いる際には、案件に合わせて項目や選択肢を調整して利用してください。

「テスト観点表のテンプレート」のダウンロードはこちら

非機能要件は「速いこと」「安定していること」のように主観的な表現が多いため、曖昧になりがちです。

このため品質特性を挙げるだけでなく、利用場面、条件、測定方法、合否基準まで具体化します（図表7）。

JSTQB Foundation Levelシラバスは、ISO/IEC 25010に基づく非機能的なソフトウェア品質特性として、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性を示しています［1］。要求項目の洗い出しには、IPAの「非機能要求グレード2018」も参考になります［2］。

例えば、性能効率性なら、「月末の締め処理中に、同時利用300人、注文データ1,000万件の条件で、検索応答時間の95パーセンタイルが2秒以内」のように、条件と基準を決めます。

数値は、業務上の許容値として関係者間で合意するようにします。

図表7：品質特性をテスト観点・テスト条件へ落とし込む例

保守性はレビューや静的解析、性能効率性は実行時の動的テストが適しています。全てをシステムテストへ集めず、早い段階のレビューやコンポーネントテストにも分散します。

テスト観点は、テスト分析でテスト条件を識別し、テスト設計でテストケースへ具体化する流れを支えるための切り口と言えるものです。

作り方としては、テストベースとプロダクトリスクを起点に、対象、操作、振る舞い、条件、品質、リスクを整理し、テストレベルや利用場面に応じて具体化します。

なお、テスト観点表は、テストケース数を増やすための単なる一覧表ではありません。何を確認し、なぜ優先するのかを関係者で共有するための有用な道具です。

ですから、テスト観点表は継続して更新することで、チームの経験を次のテスト設計へ生かせるようになります。組織におけるテスト資産として、テスト観点表を育てていくことをお勧めします。

■参考文献・参考資料■

• ［1］JSTQB Foundation Levelシラバス Version 2023V4.0.J02
• ［2］IPA「非機能要求グレード2018」（アーカイブ）