トップ
IT・DX
テスト観点とは？洗い出し方からテスト設計時の注意点まで詳しく解説

テスト観点とは？洗い出し方からテスト設計時の注意点まで詳しく解説

2023.09.05

※当サイトは人材関連サービスを展開する株式会社エイジレスが運営しています。本ページは自社および提携先のPRを含む場合があります。

【この記事を読んでわかること】
テスト観点とはテスト実施のための指針や考え方
テスト観点がないとどのような方針で何を確かめたら良いのか判断することができない
テスト観点には4つの要素が存在する
テスト観点は、テスト対象をどれだけ網羅できているかや明確であることが求められる

テスト観点とは？

ITシステム・ITソフトウェア（以降、ITシステム）開発において、対象のITシステムのテストの実施は必須ですが、そもそも何をどのようにテストを実施し、確認するのでしょうか。

テスト観点とは、テスト対象となっているITシステムの様々な機能に対して、どのようなテストを実施すれば、開発者が意図した通りの動作をしたのかを確認したことになるのかという、テスト実施のための指針や考え方です。

テスト工程のはじめの工程であり、どのような方向性・内容でテスト対象のITシステムをテストしていくかの着眼点や切り口とも考えられます。

テスト観点の例1：テストケースにテスト観点が書かれている

本来の順序としてはテスト観点を定め、テスト設計を実施し、テストケースを書いていくという流れになりますが、仮に以下のようなテストケースがある場合は太字箇所がテスト観点と呼ばれる箇所です。

住所を入力するテキストボックスの入力可能な桁数を確認する
「次へ」ボタンを押下し、画面遷移先を確認する
氏名用のテキストボックスに入力した内容が氏名欄に正しく表示されていることを確認する

※　3つ目は便宜上「正しく表示」と記載していますが何をもって「正しい」のか本来は具体的に記載すべきです。

テスト観点の例2：ECサイトで商品を一度に複数個購入の場合

次にECサイトをこれから構築する場合を例とします。

ユーザーは同じ商品を一度に複数個購入したい場合に必要な個数をテキストボックスにて指定することができるとします。

一般的に、商品の個数は「整数値」であるため開発者の思い込みで仕様書に個数の扱いについて明記されていない場合があります。そのため、1000個などの大きな数、負の数や小数点を含む「数値」、「テキスト文」をあえて入力した場合にどのような結果が想定されるのかという着眼点がテスト観点として挙げられます。

テスト観点が必要な理由

開発者からQAエンジニア・テスターなどのテスト実施者に対してテスト工程を依頼する場面において「テストしておいてください」と、曖昧な指示であった場合

どの機能について
どういう入力操作をしたら
どこに処理結果が反映されるのか
どのような結果が意図して出した結果なのか

テスト観点がない場合（丸投げの状態）はどのような方針で何を確かめたら良いのか判断することができません。非機能要件も含め、テストの目的・意図が不明となってしまいます。仕様通りに正しく動く正常系を確認するのか、バグ（欠陥）が作り込まれていないか異常系を確認するのか、そもそも実装されているか確認するのかも不明ということになります。

仮に事実上、丸投げの状態だとしても要件定義の段階から開発チーム関係者と連携している経験豊富なQAエンジニアがいるならば、ある程度はテストが進むかもしれませんが、属人化・依存度が高くなります。

経験の浅いエンジニアやテスターのみでテストメンバー構成がなされている場合は不適切なテストとなり、テストケースに抜け漏れが生じる可能性が高まってしまいます。逆に、網羅性を求めて必要以上に工数をかけた結果、効率が悪くなる場合もあります。

テスト観点の要素

図1 . テスト観点モデルにおける4つの要素

テスト観点が曖昧で的確に設定・定義されていない場合、結果としてどこかで不具合が生じる可能性が高まってしまいます。その影響により機会損失・信用失墜や人命を奪ってしまうこともあり得ます。

そのような事態を防ぐため、テストの実施は対象のITシステムの状態・挙動をどれだけ網羅し、かつ、効率的にできるかというテスト設計が重要となります。

テスト観点の4つの要素

テスト観点は上記のように、多角的な視点から洗い出していくことが求められます。そのためにテスト観点には4つの要素が存在します。

機能要素
検証方法
入力条件
出力結果

1.機能要素

テスト観点をまとめる上で「どのシステムや機能を検証（テスト）するか」を明確にします。検証すべき対象である機能・動作を要件定義書から洗い出していきます。機能要素の代表的な例として以下が挙げられます。

画面上のボタン選択時の画面遷移機能
それぞれのページにおける画面表示機能
入力時に確認のアラート機能　など

当然のことながら複数の機能が組み込まれていればいるほど、洗い出しや検証（テスト実施）にも時間を要します。

2.検証方法

検証方法とは、テスト観点において「対象のシステムや機能に対してどのように検証（テスト実施）するのか」を選定する箇所になります。それぞれの機能に対して、何を確認し、どのような検証方法を活用するのかを明確にすることが重要です。

検証方法の例としては

異常値テスト
条件網羅テスト
互換性テスト
ユーザビリティテスト

などが含まれます。
対象のITシステムや機能によって適切な検証方法を選択します。

3.入力条件

入力条件（インプットパラメータ）とは、テスト観点を考える上で、テスト対象に対して何をインプットするのか、どの値・イベントが入力・発生される可能性があるのかなどの条件です。

条件入力の例として以下が挙げられます。

スペース、0（ゼロ）、空文字、NULL
大文字小文字
うるう年などイレギュラーなタイミングがある年月日
動画を再生した後に発生するイベント、音楽が再生終了直前に曲送りにするイベント

4.出力結果

テスト対象の出力結果として、「どのようなこと（何）を観察すればいいか」という要素（結果）が必要になります。

例として出力条件にも様々な要素があり、

文字化けをしていないか
異常値を入力した際のエラーメッセージが表示されるか
音声や動画の同期をした際にずれはないか
絵文字や特殊記号のような入力を意図しない文字種が区別されているか

などが挙げられます。

テストを実施（検証）し、出力した結果において、どのようなことを確認するかを明確にすることが重要になります。

テスト観点の洗い出し方、リストの作成方法

テスト観点の一例として

ソフトウェア品質に関する国際規格ISO/IEC 9126の6つの品質特性
T.Ostrandの4つのテスト視点
Myersの14のシステムテスト・カテゴリ

の3つが有名です。

ソフトウェア品質に関する国際規格ISO/IEC 9126の6つの品質特性、T.Ostrandの4つのテスト視点、Myersの14のシステムテスト・カテゴリ

図2.テスト観点の代表例3つ

しかしながら、これらのテスト観点は視野が広く、全体像の参考にはなりますが大雑把な観点です。
実務で使えるような理解しやすく、単体テストの粒度まで細分化されたテスト観点の作成をするために

「（テスト目的）のために（テスト対象）の（部品）の（何）を確認する」

の各項目を段階的に詳細化していく形でテストリストの作成方法についてご紹介していきます。

1.テストを実施する目的を確認する

テスト対象プロジェクトの目的を達成するために、テストを実施する際には何を確認すべきか考え、テストそのものの目的を決めます。

※ 今回はプロジェクトの目的、それを実現させるためのテストの目的は予め決まっているものとします。

2.「テスト対象」をさらに細かい「部品」に分解する

一般的に、このテスト観点のリストを作成する工程に達している場合は要件定義書などの開発資料に「テスト対象」は記載済みです。しかしながら、単体テストレベルの網羅性をテスト観点に求める場合、テスト対象を適切な部品単位まで分解する必要があります。

ここでは記事冒頭に挙げた『「住所や氏名を入力するテキストボックス」と「次へボタン」がある画面が表示されている』と想定してください。

画面に見える範囲（フロント部分）では、テキストボックスやボタンなどのオブジェクトがあります。画面に見えない範囲（バックエンド部分）では、登録、参照、更新、削除などプログラムで制御された機能などが挙げられます。

どちらの範囲にも「部品」を思いつく範囲で書き出します。

3.「部品」はどのような機能をもつのか書き出す

部品まで分解した後に「それぞれの部品を何をするためのものなのか」を書き出していきます。

例として

テキストボックスはユーザーが「入力」するためのオブジェクト
ボタンは「押下」（クリック、タップ）するためのオブジェクト
登録機能は文字通りそのまま「登録」するための機能

このように「部品」がそれぞれどのような機能をもつのか書き出していきます。

4.部品の機能を実現する際に必要な単語（キーワード）をつけ、回答を書き出す

部品まで分解した後に「それぞれの部品を何をするためのものなのか」を書き出していきます。

部品の機能は何らかの「条件」「変化」「種類」「数」をキーワードとします。

ここではテキストボックスに『テスト観点の4つの要素』に記載した3つ目の「入力」を当てはめてみます。

・入力条件
「入力するための条件があるか？」
ある場合、編集権限をもつユーザーのみ入力が可能

・入力変化
「入力することによって変化があるか？」
ある場合、入力前のテキストボックスは空欄、入力後は入力内容が表示される

・入力種類
「入力の種類はあるか？（定まっているか）」
住所を想定しているため、半角数字のみ
※今回は住所を区切るための「-」は入力できないものとする。

・入力数
「入力する数はなにか？」
入力できる値、桁数

5.回答を分類し、名詞として表現する

単語（キーワード）をつけた回答を名詞にする。

・入力条件
「編集権限をもつユーザーのみ入力が可能」
つまり入力の条件として権限がある。

・入力変化
入力前のテキストボックスは空欄
→初期値は空欄
入力後は入力した内容が表示される
→表示内容

・入力種類
半角文字
→文字の種類（文字種）

・入力数
入力できる桁数
→入力桁数

6.5で名詞化した単語を「（テスト目的）のために（テスト対象）の（部品）の（何）を確認する」に当てはめる

ここまでの1から5で導き出した結果を「5で名詞化した単語を「（テスト目的）のために（テスト対象）の（部品）の（何）を確認する」に当てはめます。

例として「（テスト目的）のために『住所氏名管理システム』の『テキストボックス』の『初期値』を確認する」と当てはめると納得できる文章であるため、テスト観点にふさわしい洗い出しの1つだったことが判断できます。

もし、違和感がある、意味が通らないなどの文面となっていた場合は1から5のどこかを見直す必要があります。

テスト観点を設計する時の注意点

テスト観点は冒頭部分でも述べた通り、テスト対象をどれだけ網羅できているか（網羅性）、かつ、明確であることが求められます。

テスト観点の漏れや作業の属人化を防止するために、デシジョンテーブルやマインドマップなどを別途活用したり、要件定義書の関係者とレビューを実施することが求められます。ただし、網羅性を追求するあまり過剰な工数をかけてしまわないように効率化する必要があります。

また、テストケースの話になりますが、出力結果について『正常であることを確認する』と表に羅列されている現場を時折見かけます。テスト観点は開発者とテスト担当者が異なる場合に認識の相違を防ぐため、曖昧な表現での記載は避け、必要な時は注釈なども追記しましょう。

まとめ

テストにも目的があり、それを達成するためにはテスト観点が必要です。また、具体的なテスト観点を洗い出し、網羅性を高めるためにテスト観点のリスト化についての手法についても紹介させていただきました。

テスト観点のリストは何年ものプロジェクトでのノウハウの塊です。テスト観点は不具合を作り込まないための企業やエンジニアの資産として日々フィードバックが繰り返され、そのノウハウは「秘伝のタレ」と例えられることもあります。必ずしも過去のノウハウがそのまま活かされるとは限りませんがプロジェクトの振り返りと同様に、テストに関してもぜひ振り返りを行いましょう。

検索ワード

人気キーワード

テスト観点とは？洗い出し方からテスト設計時の注意点まで詳しく解説

おすすめの転職エージェント