
目次
そもそもテスト観点とは?
テスト観点とは、テストにおける「(テスト目的)のために(対象)の(部品)の(何)を確認する」の「何」にあたります。
これだけだと具体的にイメージしにくいと思いますので、例をあげてご説明します。
例えば、つぎのような太字個所がテスト観点と呼ばれています。
●住所入力テキストボックス(対象)の入力可能桁数(何)を確認する
●次へボタン(対象)押下の遷移先(何)を確認する
●氏名テキストボックスに入力した内容が氏名欄(対象)に正しく表示(何)されることを確認する
なぜテスト観点が必要なのか
では、なぜテスト観点が必要なのでしょうか?
それは、テストにも目的があり、その目的を達成するために「何を確認する必要があるのか」を明確にする必要があるからと言えます。
本を正すと、システム開発やソフトウェア開発のプロジェクトには必ず目的があります。
プロジェクト全体の目的は企画段階で決まり、それをブレイクダウンする形でプロジェクトを構成する開発工程などの各工程にも目的が設定されます。
当然、その工程の1つであるテスト工程にも、テストで達成すべき目的が設定され、目的に合ったテスト計画を作成し、テスト範囲、テスト内容、テスト期間などが定義されます。
このときのテスト内容を決める1要素として存在するのがテスト観点です。
なぜテスト観点が必要なのかを理解していただくために、「テスト観点(何をテストするのか)」がない場合を考えてみます。
「(テスト目的)のために(対象)を確認する」
これでは機能の「具体的に何を確認すればよいのか」がはっきりとしません。
●実装されていることを確認するのか
●仕様どおり正しく動くことを確認するのか
●予期せぬバグがないか確認するのか
「テスト観点(何をテストするのか)」があることで、確認すべき内容が明確になり、効率的にテスト目的を達成できるようになるのです。
テスト観点のつくり方

テスト観点の一例として、Thomas J.Ostrandの4つの視点(ユーザー視点、仕様視点、バグ視点、設計・実装視点)や、国際規格ISO/IEC 9126(JIS X 0129)において6つの品質特性(機能性、信頼性、使用性、効率性、保守性、移植性)があります。
しかし、これらはそのままテスト観点として使用するには、まだ粒度が粗いと言わざるを得ません。
そこで、実際にテストをするうえで理解しやすいテスト観点を作成するために「(テスト目的)のために(対象)の(部品)の(何)を確認する」の各項目を詳細にブレイクダウンする形でつくり方について解説していきます。
①テストの目的を確認する
②「対象」を「部品」に分解する
③「部品」はどんな機能をもつものかを書き出す
④部品の機能にキーワードをつけて回答を書き出す
⑤回答を分類し名詞化する
⑥「(テスト目的)のために(対象)の(部品)の(何)を確認する」に当てはめる
ひとつずつご説明していきます。
①テスト目的を確認する
プロジェクト目的を達成するために、テストでは何を確認すべきか考え、テストの目的が決まります。
※ここではプロジェクト目的、テスト目的が決まっているものとして進めます。
②「対象」を「部品」に分解する
一般的に、開発資料に影響範囲調査から判明した「対象」は記載されています。
しかし、テスト観点を作るには「対象」を適切な部品単位まで分解する作業が必要です。
では「対象」となる「部品」とは、どのようなものを指すのでしょうか?
見える範囲では、テキストボックスやボタンなどのオブジェクト、
見えない範囲では、登録、参照、更新、削除などプログラムで制御された機能などが考えられます。
部品を思いつく範囲で書き出します。
③「部品」はどんな機能をもつものか書き出す
部品まで分解できたら、「それぞれの部品が何をするためのものなのか」を書き出します。
例えば、テキストボックスは、ユーザーが「入力」するためのオブジェクト
ボタンは、「押下」(クリック、タップ)するためのオブジェクト
登録機能は、そのまま「登録」するための機能
といった要領で「部品」がどんな機能をもつのかを書き出していきます。
④部品機能にキーワードをつけて回答を書き出す
ここでは「条件」「変化」「数」「種類」をキーワードに、それぞれ考えます。
部品であるテキストボックスの機能「入力」を例にそれぞれのキーワードをつなげて考えてみます。
●入力条件
「入力するための条件があるか?」
ある→編集権限をもつユーザーのみ入力可能
●入力変化
「入力によって変化があるか?」
ある→入力前は空欄、入力後は入力内容が表示される
●入力数
「入力における数はなにか?」
→入力できる桁数、入力できる値
●入力種類
「入力の種類はなにか?」
→半角数字のみ
⑤回答を分類し名詞化する
キーワードをつけて考えた回答を分類し、名詞化するとテスト観点になります。
どういうことか実際にやってみましょう。
●入力条件
「編集権限をもつユーザーのみ入力可能=編集権限による」
→権限
●入力変化
入力前は空欄
→初期値
入力後は入力した内容が表示される
→表示内容
●入力数
入力できる桁数
→入力桁数
入力できる値
→入力値
●入力種類
半角数字
→文字種
⑥「(テスト目的)のために(対象)の(部品)の(何)を確認する」に当てはめる
①~⑤で導出した結果を「(テスト目的)のために(対象)の(部品)の(何)を確認する」に当てはめてみましょう。
納得できる文章、内容になっていれば、それはテスト観点としてふさわしいと判断できます。
意味が通らない、違和感がある文章、内容なのであれば、①~⑤を見直してみてください。
以上が、簡単なテスト観点のつくり方の流れです。
テスト観点テンプレート

ソフトウェアテストには必ず目的があり、その目的を達成するためには「何を確認する必要があるのか」を明確にする必要があります。当テンプレートは、ソフトウェアテストを行う上で「何を確認するのか」を定めるテスト観点の作成に役立つ実用的なテンプレートです。ぜひ日々の業務にご活用ください。
※当資料は、以下のコラムを見ながら行うテスト観点作成の実践を前提とした資料となっております。
(コラム)テスト観点とは?必要な理由とそのつくり方
ソフトウェアテストには必ず目的があり、その目的を達成するためには「何を確認する必要があるのか」を明確にする必要があります。当テンプレートは、ソフトウェアテストを行う上で「何を確認するのか」を定めるテスト観点の作成に役立つ実用的なテンプレートです。ぜひ日々の業務にご活用ください。
※当資料は、以下のコラムを見ながら行うテスト観点作成の実践を前提とした資料となっております。
(コラム)テスト観点とは?必要な理由とそのつくり方
テスト観点を知見のない人がつくるのはむずかしい?
「テスト観点のつくり方」で説明したように、順を追って考えていくことで、知見がなくてもテスト観点をつくることはできます。
しかし、作成されたテスト観点群がテスト目的達成のためにふさわしいものであるのかを判断することはとてもむずかしいものです。
「確認すべきテスト観点を網羅しているのだろうか?」
「過剰ではないだろうか?」
「逆に不足してはいないだろうか?」
実際に、知見がない方がつくったテスト観点では、網羅性や過不足といった点で適切でない場合が多くあります。
標準観点をもったテスト専門会社に依頼
テスト専門会社では、何千何万もの業界、システム、ソフトウェアを対象としてここでは記載しきれないさまざまなナレッジを日々積み上げています。
プロジェクトには品質、予算、期間などさまざまな要因が複雑に絡み合っています。
テスト専門会社では、積み上げた知見を駆使して、プロたちがテスト計画を作成します。
例えば、弊社SHIFTでは、年間4,000プロジェクトから得たナレッジを社内の品質プラットフォームに蓄積することで、あらゆる業界・開発手法のプロジェクトに対応できる900項目の標準観点を用意しています。これらを活用することで、たとえ開発ドキュメントがないプロジェクトでも、スピーディにオブジェクト単位のテスト設計が可能です。
このように専門的なノウハウが必要な作業ではあるため、社内に知見がない場合は、まずはテスト専門会社に相談してみるといいでしょう。
関連サービスについて
まとめ
テスト観点は「(テスト目的)のために(対象)の(部品)の(何)を確認する」の「何」を考えることで、誰にでもテスト観点をつくることはできます。
しかし、「つくること」と「適切につくること」の間には、一段高いハードルがあることを十分に理解しておく必要があります。
製品品質が求められる場合は、適切なテスト計画を作成・提案してくれるテスト専門会社に依頼するのがオススメです。