テスト観点とは？必要性や洗い出すための要素、つくり方を解説

システム開発の随所で行われるテストは、開発したシステムが正常に作動するか、システムの品質と信頼性が担保できているかを検証する工程です。テスト観点とは、テスト作業を正しく実行するために必須の考え方であり、その必要性は非常に高いものです。

本記事では、テスト観点の概要と洗い出すための要素、テスト観点の作り方について解説します。

テスト観点とは、特定の機能に対してどのようなテストを行うことが有効なのかを考えることを指します。テストケースを作成するうえで必要不可欠な要素であり、テストの精度を高めて効率的に作業するために必要とされています。具体的な例をあげると、次の太字個所がテスト観点と呼ばれる部分に該当します。

・住所入力テキストボックス（対象）の入力可能桁数（何）を確認する
・次へボタン（対象）押下の遷移先（何）を確認する
・氏名テキストボックスに入力した内容が氏名欄（対象）に正しく表示（何）されることを確認する

特定の機能に対して、どの部分をテストしなければならないのか、その方法は何がふさわしいかを考えるのがテスト観点です。テスト観点を明確にすることで、ソフトウェアテストにおける抜けや漏れを防止することができます。

▼あわせて読みたい▼
＞＞ソフトウェアテストとは？種類や目的、重要な7原則を紹介のページへ

テストケースとは、プログラムを実行する手順や入力値、条件ごとに期待される結果を明確にしたドキュメントです。誰が見てもどんなテストを実行するのかがわかるようになっており、テストケースをもとにして、手動あるいは自動化ツールを用いてテストを実施します。

テスト観点との違いは、具体的な手順なのか考え方なのかの違いです。テスト観点は、テストを実施するために必要な考え方や着眼点であり、具体的なテストの手順には言及しません。テストケースを作成する際には、テスト観点に従ってどのような手順でテストを実施するのかを明確にする必要があります。そのため、テストケース作成時にはテスト観点をはっきりさせておかなければならないのです。

いいかえれば、テスト観点はテストのベースであり、テストケースはそのベースをもとにした手順書となります。両者は全く別物ですが、相互に必要となる役割があるものであることを忘れてはいけません。

テストケースに関してはこちらもご覧ください。
＞＞テストケースとは？書き方や満たすべき要件について解説のページへ

テスト観点が必要な理由は、テストの目的を達成するために「何を確認する必要があるのか」を明確にする必要があるためです。

システム開発のプロジェクトには必ず目的があります。プロジェクト全体の目的は企画段階で決まり、それをブレイクダウンする形でプロジェクトを構成する開発工程などの各工程にも目的が設定されるのです。

当然、その工程の1つであるテスト工程にも、テストで達成すべき目的が設定されます。目的に合ったテスト計画を作成し、テスト範囲やテスト内容、テスト期間などが定義されます。このときのテスト内容を決める1要素として存在するのがテスト観点です。

仮に、テスト観点がない場合、実装する機能に対して具体的に何を確認すればよいのかがはっきりとしません。その結果、次の項目がわからなくなる可能性があります。

・実装されていることを確認するのか
・仕様どおり正しく動くことを確認するのか
・予期せぬバグがないか確認するのか

上記以外にも、テスト観点がないとなおざりになってしまうポイントは多くあります。テスト観点は、開発したシステムの品質を保証するために必要不可欠な考え方であると同時に、効率的にテスト目的を達成するために必須なものなのです。

テスト観点を洗い出すためには、次の4つの要素を中心に考えるようにしましょう。

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

テスト観点を考えるためには、上記の4つの要素を組み合わせる必要があります。各テスト観点の要素を知り、品質担保や信頼性維持に努めましょう。

機能要素とは、表示機能や画面遷移機能など、開発したシステムに搭載された機能のことです。検証する機能や関連する動作を、基本設計書から洗い出します。

動作に対して基本設計書通りの機能をするかなどを確認しなければなりません。また、複数の機能が搭載されているソフトウェアの場合、どのアクションがどの機能につながるのかも明確にする必要があります。時間はかかりますが、テスト観点を検討するうえで欠かせない要素でもあります。

検証方法とは、対象となる機能に対する検証の手法のことです。確認する機能によって確認するポイントや検証にふさわしい方法は何かを検討します。機能によって異なりますが、具体的には次のような検証方法があります。

・表示内容確認
・動作確認
・組み合わせ確認

どの検証方法を用いるのかを検討し、選択するようにしましょう。

入力条件とは、テスト対象に対してどんな値やイベントを入力するかなどの条件のことです。具体的にはスペースや大文字小文字を入力したときに発生する可能性があることを洗い出す条件を指します。

入力条件の例は、ほかにもあります。例えばカレンダーに反映するうるう年などは、入力条件に該当する条件です。ほかにも音楽や動画の終了後に発生するイベントも、入力条件のひとつです。

出力結果とは、特定の数値や文字・アクションを入力した際に何が起こるのかを観察することです。入力条件の結果起こるイベントとも考えらえます。

特定の文字などを入力した際に異常は発生しないか、異常値を入力したときにエラーを起こさないかだけではなく、文字化けや動画・音声のずれも出力結果のひとつです。

これら4つの要素から、テスト観点は成り立っています。多角的な視点からこれらを洗い出すようにしましょう。

テスト観点の一例として、次のようなものがあります。

・Thomas J.Ostrandの4つの視点
　ユーザー視点、仕様視点、バグ視点、設計・実装視点

・国際規格ISO/IEC 25010（JIS X 25010）における8つの品質特性
　機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性

しかし、これらはそのままテスト観点として使用するには、まだ粒度が粗いといわざるを得ません。そこで、実際にテストをするうえで理解しやすいテスト観点を作成するために、テスト観点の各項目を詳細にブレイクダウンする形で作る方法について解説していきます。手順は次の通りです。

①テストの目的を確認する
②「対象」を「部品」に分解する
③「部品」はどんな機能をもつものかを書き出す
④部品の機能にキーワードをつけて回答を書き出す
⑤回答を分類し名詞化する
⑥「（テスト目的）のために（対象）の（部品）の（何）を確認する」に当てはめる

ひとつずつ詳しく見てみましょう。

プロジェクト目的を達成するために、テストでは何を確認すべきか考えることで、テストの目的が決まります。考えられるテストの目的は次のようなものが代表的です。

・仕様書通りの機能を有しているか
・画面の表示や操作に問題はないか
・複雑な機能は問題なく動作するか

上記以外にも、プログラムに応じたテストの目的を考える必要があります。開発者とテスターが必ずしも同じではないことも関係していますが、あいまいな指示や目的のままでは、何をどのようにテストするのかが不明瞭になってしまいます。テスターに対して明確なテストの指示を出すためにも、テスト目的は明確にしなければならないのです。

なお、ここではプロジェクト目的、テスト目的が決まっているものとして進めます。

「対象」を「部品」に分解するとは、アクションを起こすのに動作が求められる部分はどこなのかを明確にすることです。一般的に、開発資料に影響範囲調査から判明した「対象」は記載されています。しかし、テスト観点を作るには「対象」を適切な部品単位まで分解する作業が必要になるのです。

具体的な「部品」は以下の通りです。

・見える範囲：テキストボックスやボタンなどの画面部品
・見えない範囲：登録、参照、更新、削除などプログラムで制御された機能

ほかにもいくつかの該当する「部品」が存在する場合があります。開発資料を参考に、思いつく範囲で書き出しましょう。

「部品」まで分解できたら、それぞれの部品が何をするためのものかを書き出します。いいかえれば、ユーザーが部品に対して起こすアクションを考えることです。具体的には、次のようなことが考えられます。

・テキストボックス：「入力」するためのオブジェクト
・ボタン：「押下」（クリック、タップ）するためのオブジェクト
・登録機能：何らかの情報を「登録」するための機能

このように、「部品」がどんな機能をもつのかを書き出していきます。仕様書や開発資料を見て、どのような機能があるのかを整理してください。

ここでは「条件」「変化」「数」「種類」をキーワードにそれぞれ考えます。部品であるテキストボックスの機能「入力」を例にそれぞれのキーワードをつなげて考えてみましょう。

【テキストボックスの機能「入力」例】

こうすることで、特定のアクションに対してどのような変化が起こるのかが明確になります。ひとつの部品につき、複数の回答が得られる場合もあるため、それらもすべて書き出すようにしてください。

キーワードをつけて考えた回答を分類し、名詞化するとテスト観点になります。名詞化とは、回答を端的な名詞に置き換えることです。具体的にどういうことか、実際の例を見てみましょう。

名詞化を行うことで、システムの基本構造が構築できます。

①～⑤で導き出した結果を「（テスト目的）のために（対象）の（部品）の（何）を確認する」にあてはめてみましょう。具体的には次のようになります。

・テキストボックスの機能が正常かを確認するために、テキストボックスの入力の権限を確認する
・ボタンの機能が正常かどうかを確認するために、ボタン押下の入力値を確認する

上記のように納得できる文章、内容になっていれば、それはテスト観点としてふさわしいと判断できます。意味が通らない、違和感がある文章・内容なのであれば、①～⑤を見直してみてください。

以上が、簡単なテスト観点のつくり方の流れです。

「テスト観点のつくり方」で説明したように、順を追って考えていくことで、知見がなくてもテスト観点をつくることはできます。しかし、作成されたテスト観点群がテスト目的達成のためにふさわしいものであるのかを判断することはとても難しいものです。実際に、知見がない人がつくったテスト観点では、網羅性や過不足といった点で適切でない場合が多くあります。

テスト観点を作成するのは、経験豊富な人材がベストです。とはいえ、属人化を防ぐためにはひとりの経験者に任せきりにするのも良くありません。知見がない人がテスト観点を作成した際は、経験者にチェックしてもらうなどを通して、テスト観点の作成ができる状態に育てる意識も必要です。

テスト観点には、テスト観点リストと呼ばれるテンプレートがあります。テスト対象ごとに大項目・中項目というようにまとめられているもので、知識がない人でも比較的容易にテスト観点を書き出すことができます。ただし、最終的には経験者などの確認を求めるようにしてください。

SHIFTでも、テスト観点作成に役立つテンプレートを活用しています。ソフトウェアテストに求められる目的を達成するためには「何を確認する必要があるのか」を明確にする必要があります。SHIFTのテンプレートは、ソフトウェアテストを実施する際に確認すべきことを決めるのに役立つ実用的なものです。ぜひご活用ください。

テスト専門会社では、何千何万もの業界、システム、を対象としてここでは記載しきれないさまざまなナレッジを日々積み上げています。プロジェクトには品質、予算、期間などさまざまな要因が複雑に絡み合い、テスト専門会社では、積み上げた知見を駆使して、プロたちがテスト計画を作成しているのです。

例えば、SHIFTでは、年間4,000プロジェクトから得たナレッジを社内の品質プラットフォームに蓄積することで、あらゆる業界・開発手法のプロジェクトに対応できる900項目の標準観点を用意しています。これらを活用することで、たとえ開発ドキュメントがないプロジェクトでも、スピーディにオブジェクト単位のテスト設計が可能です。

このように専門的なノウハウが必要な作業ではあるため、社内に知見がない場合は、まずはテスト専門会社に相談してみるといいでしょう。

テスト観点は、テストケースの作成の土台になる非常に重要な部分です。テスト目的や実施する対象、そして何をテストするのかを考えて、テスト観点を作成しましょう。テスト観点があいまいなままでは、完成した製品によって悪影響が生じる可能性もあります。これらを防ぎ、ユーザーが不満を抱かずに使用するためにも、テスト観点の作成は非常に重要な工程といえるでしょう。

SHIFTでは、テスト観点の作成が可能です。年間4,000件のプロジェクトで培った標準観点を活用し、お客様のテスト観点を作成できます。また、ソフトウェアテストだけではなく、開発も可能です。テスト観点の作成や、そもそも開発の段階でお悩みを抱えている場合も、ぜひSHIFTまでご相談ください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

よくある質問はこちら
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座