テスト技法・工程

2025.02.14

テストの観点とは？使いやすいテスト観点リストの構造・整え方を解説

執筆：堀明広

バルテス・ホールディングス株式会社 R&C部部長兼首席研究員

テストを設計する上で、「テストの観点」は非常に重要なものです。しかし、その「テストの観点」をまとめた「テスト観点リスト」が形骸化し、実務で使われない、というケースが生じている所もあります。

本稿では、テストの観点とは何かを「テスト観点モデル」で改めて整理し、テスト観点リストの基本的な構造を示していきいます。

もくじ

「テストの観点」とは
1. テストの観点とは
2. テスト観点リスト＝テストの観点をまとめたもの
テスト観点リストはせっかく作っても使えないことがある
使いやすくするには「テストの観点」を理解することが重要！
テストの観点を項目分けした「テスト観点モデル」４つの要素
テスト観点モデルに基づき、テスト観点リストを整理しよう
まとめ

1．「テストの観点」とは

1-1　テストの観点とは

テストの観点とは、ソフトウェアが正しく動作するかを確認するための項目、着眼点、発想の仕方といった、いわばテストを行う上での「切り口」のようなものです。

このテストの観点はソフトウェアテストのテスト設計においてとても重要になります。

1-2　テスト観点リスト＝テストの観点をまとめたもの

テストの観点をまとめたものを、本稿では「テスト観点リスト」と呼びます。

テスト観点リストは何のために用いられるか、その目的を改めて整理すると、以下のようになります。

過去に得た知見を再利用し、テスト設計の効率を上げる
過去に得た知見を再利用し、テスト設計とテストの実施の双方で、漏れ抜けを防止する

テスト観点リストは、テストの設計と実施のためのナレッジマネジメントを行うためのツールと言え、多くの組織で作成しています。

元開発者から見た、テストの質を上げる「テスト観点リスト」の大切さ| Qbook

2．テスト観点リストはせっかく作っても使えないことがある

使いづらい.png

テスト観点リストは、テストの漏れ抜けの防止とテスト設計の効率化を図る上で非常に重要なツールです。
しかし、テスト観点リストが作成されて一度は目が通されても、再読されずに肝心のテスト設計時には使われないというケースがあります。これではテスト観点リストは時限的な「資料」の域を出ず、テストのナレッジを共有するためのツールや資産とは言えません。

使われない知見やツールは、当然ながら改善もされないものです。一念発起してテスト観点リストを作ってもそれが使われない。そんな状況では、テスト観点リストに新たに項目を追加したり更新したりすることもしまうかもしれません。せっかく作られた観点リストが形骸化し、効率化・抜け漏れの防止といったテストの改善が進まず、個々のテストエンジニアのスキルアップも進まない、ということにもなってしまいます。

では、せっかく作ったテスト観点リストが使われないのはなぜなのでしょうか。その原因はいくつかありますが、テスト観点リストの作り方、各々のテスト観点の整理の仕方に大きな問題を抱えているケースが多いようです。

具体的に言いますと、テスト設計リストの項目分けに問題があります。

テスト観点の問題.png

よく見かけるテスト観点リストは「大項目」「中項目」「小項目」といったように、階層構造で整理されていますが、何に大項目を入れるのか、何に中項目を入れるといった、項目分けのルールが不明確で、バラバラになっています。

テスト観点リストの内容が、それほど多くなくて全体が俯瞰できるのであれば、整理が多少悪くても大きな問題にはならないでしょう。しかし、テスト観点リストの項目が増えてくると、閲覧性がとても重要になってきます。うまく整理されていない数百件以上のテスト観点のリストを見て使えと言われても、手に負えるものではないからです。

うまく整理されていない、すなわち閲覧性が悪いテスト観点リストは、たとえリスト中の個々の内容が良いものであっても、とても使いにくいものになってしまいます。

テストの現場では時間との勝負ですから、必要な情報がすぐに引き出せないテスト観点リストを苦労して読み解くよりも、ハナから自分でテスト設計した方が速い、ということになってしまうわけです。

ソフトウェアテストの勘所 | Qbook

3．使いやすくするには「テストの観点」を理解することが重要！

理解.png

使いやすくするために、大中小項目の使い分けを統一したら良いかというと、そういう問題ではありません。筆者もそれを試みたことがありますが、うまく整理できませんでした。

筆者が見てきたテスト観点リストは、その内容の全部が全部、でたらめになっていたわけではありませんでした。一見、ごちゃごちゃしていてまとまりが無いように見えるテスト観点リストの中から、あるまとまりを抜き出してその部分内を見ると、大中小の項目分けが妥当な形で分類されていました。
しかし、同じテスト観点リスト中の別のまとまりを見ると、そこではまた別のルールで、しかもその部分の範囲内では妥当な形で大中小項目が分けられていました。このように、テスト観点リストを部分的に見ると統制が取れているものの、全体的に見ると、一つのテスト観点リスト中に大中小項目の使い方のルールがいくつも混在し、その結果、全体的にまとまりが無い、という状態になっていました。

各所でまとめられた観点リストを集めて単純にマージしては、膨大で混沌とした、利用不能なテスト観点リストになってしまいます。そうであれば、テスト観点リストの「大項目」「中項目」「小項目」の使い分けの定義を統一すれば問題解決するのではないかと整理を試みましたが、テストの観点にはさまざまなものがあるため、項目分けのルールを統一するには無理がありました。

要する目的としては、「テスト観点リストをまとめやすくする」「テスト観点リストを閲覧しやすく、利用しやすくする」ということなのですが、これを達成するには、もう一度「テストの観点とは何なのか」というところまで立ち戻って理解することが重要でした。

次章では、改めて、そもそもテストの観点とは何なのか、というテーマで解説します。

4．テストの観点を項目分けした「テスト観点モデル」4つの要素

テストの観点とは、ソフトウェアが正しく動作するかを確認するための項目、着眼点、発想の仕方といった、テストを行う上での「切り口」のようなものですが、その切り口には色々なものがあります。しかし、その「切り口」とはどんなものがあるか曖昧で、これが、テスト観点リストがうまく整理できずに混沌としたものになってしまう原因になっているのです。

そこで、「テストの観点」とは何かを改めて整理し、それに基づいてテスト観点リストの構造を再構築するアプローチを取りました。

まず始めに、「テストの観点」とは何かを改めて整理するため、一般的に「テストの観点」と呼ばれているものを列挙し、それらがどのような意味と位置付けを持っているかを分析して項目分け関連付ける形で、「テスト観点モデル」としてまとめました。以下に概念図を示します。

図１．テスト観点モデル

tkmodel1

テスト観点モデルは、上記のように、大きく分けて4つの要素で構成されています。

①機能要素　②検証アングル　③テストパラメータ　④確認ポイント

それぞれ解説していきます。

※テスト観点モデルの構成要素は他にもあるのですが、テスト観点リストの内容を説明するには不要なので、本稿では割愛します。

① 機能要素

例えば、画面表示テスト、画面遷移テスト、入力確認テスト、接続動作テスト、再生動作テスト、セキュリティテストといったものです。
このように、テスト対象で、検証すべき機能を分解してシンボリックに表すものです。

② 検証アングル

例えば、通常バリエーションテスト（正常系テスト）、正常限界値テスト、準正常系テスト、異常系テスト、機能複合・競合テスト（組み合わせテスト）、構成テスト（互換性テスト）、ローカリゼーションテスト、ストレステスト、エージングテスト、性能テスト、ユーザビリティテスト、といったものです。
このように、テストする機能に対し、どんな条件で、どんな特性を検証するかを表すものです。

③ テストパラメータ

例えば、入力する文字に対し、どんな文字種を与えるか。（全角・半角・英数字・漢字・記号等。またそれらの偏重（大文字のみ、小文字のみ等）、混在（大文字と小文字の混在）。
例えば、スマートフォンを工場出荷状態にする、メモリフルの状態にする。
例えば、音楽再生直後に曲送りする、音楽再生終了直前に曲送りするなどのイベント。
このように、テストする機能に対し、どんな値や状態を与えるか、どんなイベントを発生させるかといったように、テスト対象にどんなものを"input"するかを表すものです。

④ 確認ポイント

例えば、画面表示テストであれば、画面表示の構成要素の文言が仕様と不一致のところがあるか、文字切れや文字化けが起きていないか。
例えば、スマートフォン等の動画再生動作テストであれば、動画と音声の同期ズレが起きていないか。
このように、テスト対象が正常に動作しているか、仕様とマッチしていないところは無いか、異常動作するとしたらどんな症状を示すか、といったように、テスト対象の振る舞い（output）のどこを観察するかを表すものです。