ソフトウェアテストの観点とは？洗い出し手順や網羅性を高めるコツを解説

ソフトウェアテストにおいて役割が異なります。テスト観点は、どの部分を確認すべきかを定めるための思考の軸です。

一方、テストケースはその観点をもとに構築される実施手順です。具体的には、入力値や動作条件、期待される出力を具体的に記述した設計書にあたります。

テスト観点が「何を検証すべきか」という指針だとすれば、テストケースは「どのように検証するか」を形にしたものです。両者は性質こそ異なりますが、品質を高めるうえで欠かせません。

※こちらの記事では、ソフトウェアテストについて詳しく解説しています。
　必要性や7原則についても取り上げているため、ぜひあわせてご覧ください。

機能要素とは、以下のようなシステムが提供する具体的な機能のことです。

● 画面の表示処理
● ボタン操作に応じた遷移
● ユーザー操作への応答

まずは仕様書や設計書をもとに、検証対象の機能を網羅的に抽出しましょう。たとえば、ページごとの表示内容が正しいか、ボタンを押すと想定どおりに次の画面へ進むかなどです。

ほかにも、入力ミスに対して適切な警告が表示されるかなど、ユーザーの操作に対する挙動を丁寧に確認します。こうした機能ごとの視点を明確にすることで、確認漏れを防ぎながら精度の高いテスト設計が可能になるでしょう。

対象となる機能に対して、どのような手段で確認を行うかを決める工程です。確認したいポイントによって、適切な検証手法を選定する必要があります。

具体的には、以下のような方法があります。

● 画面に表示される文言が正しいかを確認する表示検証
● 機能が意図どおりに作動するかを確かめる動作検証
● 複数の条件を組み合わせて挙動を確認するパターン検証

また、異常値を入力してエラーハンドリングを確認する負荷テストや複数の環境での挙動を調べる互換性テストなども有効な手段です。検証方法を誤ると、本来確認すべき動作を見落とすおそれがあるため、注意しましょう。

テスト対象にどのような値や動作が与えられるかを定義する要素です。ソフトウェアが想定外の入力に対しても、安定して動作するかを確認するうえで欠かせない観点です。

たとえば、数値入力欄にマイナスや小数が入る場合、テキスト入力で以下のようなあらゆるケースを確認する必要があります。

● 全角
● 半角
● 大文字と小文字の混在
● 空白や改行の有無

ほかにも、カレンダー機能でうるう年が正しく反映されるか、再生中の音楽が終了間際に操作された際の挙動なども対象となります。入力条件を適切に設計することで、実際の利用状況に近い動作確認が可能となり、バグの早期発見につながります。

特定の入力や操作に対して、システムがどのような応答を示すかを確認する項目です。入力条件に基づいて引き起こされる画面表示や動作の変化などを検証対象とします。

たとえば、以下の事例が該当します。

● 誤った値を入力した際に適切なエラーメッセージが表示される
● 入力内容が文字化けする
● 音声や映像が意図どおりに再生されない

こうした予期せぬ結果が現れた場合は、仕様との齟齬やバグの可能性があるため、見逃してはなりません。加えて、ユーザー視点での視認性や反応の正確さなどにも十分配慮する必要があります。

最初に行うべきは、テストの目的をはっきりさせることです。目的が曖昧なままでは、検証すべきポイントがぼやけてしまい、効果的なテストにつながりません。

開発者とテスト担当者が異なる場合、共通認識を持つためにも、何を検証するかを具体的に定めましょう。テストの方向性をチームで共有し、統一した視点で進めるためにも目的の設定が欠かせません。

対象を構成する機能や操作要素を部品単位で洗い出す必要があります。画面上に表示されるテキスト入力欄やボタンのような要素はもちろん、裏側で処理を担う登録・更新といった機能も対象に含めて分解しましょう。

すでに開発資料に対象範囲が記載されている場合でも、テスト精度を高めるにはより細かい単位にまで落とし込むことが求められます。見える範囲と見えない範囲の両面から構成要素を洗い出すことで、漏れが生じづらくなるでしょう。

構成要素を部品単位で洗い出したあとは、それぞれがどのような動作や目的を担っているかを明確にする必要があります。たとえば、テキストボックスはユーザーが文字を入力する操作に対応し、ボタンはクリックなどの操作で処理を実行します。

このように、各部品がユーザーのどんな操作に応じてどのような働きをするのかを整理することで、テストの視点がより具体的になるでしょう。

要素の役割を整理したあとは、それぞれに対してどのような観点で確認すべきかを具体化していきます。ここで活用できるのが、以下4つの視点です。

● 条件
● 変化
● 数
● 種類

たとえば、入力機能をもつテキストボックスであれば、以下のような切り口で考えます。

● 誰が入力できるなどの条件
● 入力後における表示の変化
● 入力可能な桁などの数
● 半角のみ対応かなどの種類

こうして多角的に確認事項を洗い出すことで、テスト観点をより網羅的に構築できるでしょう。複数の要素が含まれる場合もあるため、それぞれ丁寧に整理しておくことが不可欠です。

確認すべき内容を具体化したあとは、それぞれを名詞へ置き換えましょう。これは、テスト観点として整理する際に重要な工程です。

たとえば「編集権限をもつユーザーのみが入力できる」といった内容は「権限」と名詞化できます。同様に、入力前の状態は「初期値」入力後の表示は「表示内容」と表現できます。

名詞にまとめることで観点がシンプルになり、関係者間での認識を揃えやすくなるでしょう。

導き出した確認事項を型にあてはめて整理することで、テスト観点としての妥当性を確認できます。形式に落とし込むと、内容の整合性や論理性が明確になります。

たとえば「テキストボックスの仕様が適切かを検証するために、入力機能の権限設定を確認する」と表現できれば、テスト対象・目的・確認点が過不足なく整理されているといえるでしょう。

ゆもつよメソッドは、テスト観点の整理と粒度の統一を重視した手法です。「何の機能を対象に」「何を検証し」「どのようにテストするか」を明確に切り分けて進める工程が整っている点が特徴です。

はじめに仕様を読み解き、機能ごとにテスト対象をリストアップします。次に、機能ごとに確認すべきポイントを抜かりなく整理し、テストカテゴリとして分類します。

その際、カテゴリごとにどのような問題が発生しうるかを具体的に検討し、不具合例や期待される動作を明記しましょう。最後には機能一覧やカテゴリを表にまとめることで、全体を俯瞰しやすくなり、網羅性の確保や粒度の統一に役立ちます。

ゆもつよメソッドでは、観点の粒度がばらつかないように整理できるため、チーム間で認識も統一しやすくなります。

VSTePはテスト観点を体系的に整理し、漏れを減らすための手法です。電気通信大学の西康晴氏が考案し、観点ごとの整理や視覚化を通じて、テスト全体を俯瞰できる構造を構築します。

観点は、専用の記述ルールを使って整理されています。ツリー構造の図として描くことで、関係性や抜けている要素を把握しやすくなる点もポイントです。

テスト項目の集まりをひとつの枠として図示したり、ケース作成に役立つ雛形を用意したりするなど、開発工程での活用にも対応できるでしょう。すでに存在するテストケースを再構築し、観点ごとに整理し直す際にも役立ちます。

このように、VSTePは過去のテストを再活用する際にも適しています。テスト観点の粒度が曖昧な場合や、レビューに時間がかかる現場ではとくに有効です。

HAYST法は、ソフトウェアテストの分析から実行までを整理しやすくするためのフレームワークです。名称は「Highly Accelerated and Yield Software Testing」に由来し、効率と成果の両方を意識した設計が特徴です。

元々は直交表という技法を利用して要素同士の組み合わせパターンを整理し、無駄なくケースを構成する手法として発展しました。現在では、機能の抽出や条件整理といった準備段階から活用され、組み合わせの偏りや漏れを抑えるための指針としても機能しています。

テスト対象の特性や目的に応じて要素や数値を慎重に選べば、効率的な設計が可能になるでしょう。HAYST法を使えば、組み合わせパターンの偏りを抑えつつ、検証すべき条件を効率よく抽出できます。

テスト観点の網羅性を高めるためには、4つの視点を活用する方法が有効です。このフレームワークでは、以下の4方向からソフトウェアを検証します。

● ユーザー視点
● 仕様視点
● バグ視点
● 設計視点

ユーザー視点では、利用者の操作に基づく動作確認を行い、誤操作や想定外の入力に対する反応を確かめます。仕様視点では、設計書どおりに処理が実行されているかを確認し、仕様の充足度を評価します。

バグ視点では、異常系の動作や障害が発生しうる状況を意図的に試し、弱点を探ることがねらいです。設計視点では、内部構造に潜むリスクやパフォーマンス上の問題を検討し、堅牢性を検証します。

複数の視点を併用することで、一方向の観点では見落としがちな欠陥にも気づけるでしょう。

ソフトウェアの品質を評価するための指標として、国際規格ISO/IEC 25010に基づく「製品品質モデル」が広く用いられています。このモデルでは、以下8つの特性が定義されており、それぞれに具体的な副特性が設けられています。

● 機能適合性
● 性能効率性
● 互換性
● 使用性
● 信頼性
● 安全性
● 保守性
● 移植性

たとえば、機能適合性のなかには「機能正確性」や「機能完全性」が含まれ、期待される動作や出力の正しさを確認することが求められます。性能効率性は、処理時間やシステム資源の使用量が一定の基準を満たしているかを確認します。

Myersの提唱するシステムテスト・カテゴリは、ソフトウェアの品質を多角的に検証するための視点として、現在も有効に活用されています。機能の正当性を確認するテストから、以下のような幅広い領域を対象としている点が特徴です。

● 負荷や容量に対する耐性
● 使いやすさやセキュリティの確認
● 文書や手続きに関する検証

たとえば、ストレステストではシステムに過剰な処理を与えたときの反応を確認し、回復テストでは障害発生後の復旧動作を評価します。いずれも、テスト観点の網羅性を確保する際に役立つでしょう。

作成するには、観点を段階的に整理することが重要です。まず大項目としてシステム全体の視点を定め、次に中項目で機能ごとの分類を行い、最後に小項目で具体的な操作や条件を掘り下げていきます。

このように範囲を段階的に絞り込むことで、観点の抜け漏れを防ぎつつ、誰が見ても理解できる体系的なリストになるでしょう。

主なリストの作り方は、以下のとおりです。

● フレームワークを大項目に置く
● 機能要素を大項目に置く

それぞれの工程について解説します。

例1：フレームワークを大項目に置く

まずは全体の枠組みを定めましょう。とくに、多岐にわたる要素を扱うプロジェクトでは、いきなり細かい点に目を向けるのではなく、最初に物事の本質や構造を大づかみに捉える姿勢が求められます。

そのとき役立つのが「フレームワーク」を起点とした整理法です。たとえば、品質管理やソフトウェア開発において、FMEAやV字モデルなどのように体系立てられた枠組みを大項目として設ければ、思考が整理しやすいでしょう。

まずはフレームワークを柱とし、そこから必要な観点を漏れなく分類していく流れとなります。そのため、全体像を見失うことなく、各要素の関係性を保ちながら展開できるでしょう。

結果として、見通しのよいテスト観点リストを構築しやすくなり、関係者間の共通認識の形成にもつながります。

例2：機能要素を大項目に置く

機能単位で観点を整理する方法もあります。この手法では、画面表示や入力チェック、データ登録といった具体的な機能を大項目として設定します。その下に中項目・小項目を順に分類するため、実務で直感的に把握しやすい構造を実現できます。

たとえば、入力機能における観点では、未入力や文字種などを細かく分類します。期待される動作が明示されているため、網羅性と再利用性に優れているといえるでしょう。

そのため、Webアプリケーションの開発に広く用いられる「Laravel」のような特定の技術要素を含むプロジェクトでも柔軟に対応でき、各種ケースを見落とすことなく設計できる点が強みです。

関数やメソッドなどの最小構成単位に対して、想定どおりの動作をするかどうかを確認するテスト工程です。実施単位はプロジェクトの性質によって異なるため、画面単位やバッチ処理単位で進めるケースも見られます。

画面内の各ボタンに紐づく処理を個別に検証し、分岐条件をすべて通過させることを目的とするホワイトボックステストが基本です。また、視覚的な表示崩れなど、UI面の確認も少なくありません。

テストに用いるデータは、あらかじめ自作する場合が多いです。したがって、作成の負担を軽減するには、先にテスト用の登録機能を整備しておくことが効果的です。たとえば、照会画面を確認したい場合には、まず登録機能を用意し、必要な情報をスムーズに準備できる体制を整えることが求められます。

複数の機能やモジュールを組み合わせた際に、連携が意図どおりに行われるかを検証する工程です。主にサブシステム内部の連携を確認する内部結合テストと、複数のサブシステムや他システムとの接続部分を確認する外部結合テストに分類されます。

内部結合では、画面やバッチ処理など、ひとつのまとまりの中でデータが正しく受け渡されるかを重視します。一方、外部結合ではシステム間のインターフェースの整合性やバグの有無に着目します。

いずれも送信側が出力したデータをそのまま受信側で使用し、通信や処理の連携が問題なく進むかどうかを確認します。

完成したソフトウェア全体が仕様どおりに動作するかを確認する工程です。個別の機能を検証する段階を経て、最終的に一連の流れが実運用と同じ手順で問題なく進行するかを検証します。

たとえば、会員登録からログイン、マイページへの遷移といった一連の処理を通じて、機能同士が正しく連携しているかをチェックします。工程が進むと観点がより具体的になり、画面表示のずれなどの細かなバグも見つけやすくなる点が特徴です。

テスト観点を設定する際には、何を検証したいのかを明らかにすることが重要です。テスト設計者と実施者が異なるケースでは、観点の解釈にずれが生じやすくなります。

そのため、曖昧な表現は避け、誰が読んでも意図が伝わる記述を心がける必要があります。たとえば「空白時の動作を確認」ではなく「未入力のときにエラーメッセージ『必須項目です』が表示されるかを確認する」と記載するなどです。

用語の難解さや表現の抽象度にも注意し、必要に応じて補足や注釈を加えましょう。こうすることで、認識の統一を図れます。

観点を分類する際には、機能ごとや処理単位で整理し、目的に沿った構成となっているかを意識することが大切です。

求められる品質の水準とテストに割ける期間を明確にする必要があります。リリースに必要な最低限の動作確認でよいのか、あるいは高い完成度を求めるのかによって、観点の粒度やカバー範囲が異なるためです。

また、どれだけ精緻な観点を設定したとしても、時間的な制約がある場合には、優先順位をつけて実施可能な範囲に収める判断も求められます。加えて、仕様を正しく理解しておくことも欠かせません。

ユーザーの操作手順を想定しながら、流れごとにバグを見つけ出せるよう観点を分解しましょう。リスクの高い領域から順に重点を置くことが成果を出すためのポイントといえます。

機能仕様だけでなく、画面を利用する人の視点も意識しましょう。入力欄やボタンなどの操作部品に注目するだけでなく、各項目の必要性や使う状況を具体的に想像することが重要です。

たとえば、以下のような観点もユーザーの満足度につながります。

● リンクが正しく遷移するか
● ヘッダー構成が直感的に理解できるか
● レイアウトが目的に適しているか

部品ごとに丁寧に仕様を確認しながら、不明点があれば開発側に積極的に確認することで、認識のずれを防げるでしょう。

テスト観点の洗い出しでは、主観だけに頼るのではなく、他者の視点を積極的に取り入れることが不可欠です。自身では十分だと感じた観点でも、別の視点から見ると見落としがある場合は少なくありません。

実際、アプリやWebサイトをリリースする前に、十分なテストが行われていることが重要だと感じている人は非常に多いです。60代以下の全国の男女（有効回答数740）へ実施したアンケートでは「アプリやwebサイトなどをリリースする前に、しっかりテストされていることは重要だと思いますか？」という質問に対し「とても思う」と回答した人が全体の66.6％を占めています。

調査データ引用元： https://prtimes.jp/main/html/rd/p/000001581.000044800.html


こうしたユーザーの期待に応えるには、企画・設計・実装といった各フェーズで第三者によるレビューを行い、観点の抜けや重複を早期に発見することが求められます。上司や担当者に相談し、レビューの機会を設けましょう。