テストを設計する上で、「テストの観点」は非常に重要なものです。しかし、その「テストの観点」をまとめた「テスト観点リスト」が形骸化し、実務で使われない、というケースが生じている所もあります。本稿では、テストの観点とは何なのかを「テスト観点モデル」で改めて整理し、テスト観点リストの基本的な構造を示しています。
「テストの観点」とは
さまざまな所で「テストの観点とは何か」が説明されていますが、その多くは以下のように内容になっています。
「ソフトウェアが正しく動作するかを確認するための項目、着眼点、発想の仕方といった、いわばテストを行う上での「切り口」のようなもの」
テストの観点をまとめたものを、本稿では「テスト観点リスト」と呼んでいます。
テスト観点リストは何のために用いられるか、その目的を改めて整理すると、以下のようになります。
・過去に得た知見を再利用し、テスト設計の効率を上げる
・過去に得た知見を再利用し、テスト設計とテストの実施の双方で、漏れ抜けを防止する
テスト観点リストは、テストの設計と実施のためのナレッジマネジメントを行うためのツールと言え、多くの組織で作成しています。
「テスト観点リスト」の問題とその原因
せっかく作ったテスト観点リストが使えない!
上述しているように、テスト観点リストは、テストの漏れ抜けの防止とテスト設計の効率化を図る上で非常に重要なツールです。
しかし、テスト観点リストが作成されて一度は目が通されても、再読されずに肝心のテスト設計時には使われないというケースがあります。これではテスト観点リストは時限的な「資料」の域を出ず、テストのナレッジを共有するためのツールや資産とは言えません。
使われない知見やツールは、当然ながら改善もされないものです。
一念発起してテスト観点リストを作ってもそれが使われない。そんな状況では、テスト観点リストに新たに項目を追加したり更新したりすることもしまうかもしれません。そうなっては、せっかく作られた観点リストが形骸化し、効率化・抜け漏れの防止といったテストの改善が進まず、個々のテストエンジニアのスキルアップも進まない、ということにもなってしまいます。
テスト観点リストが使われないのは何故か?
では、せっかく作ったテスト観点リストが使われないのはなぜなのでしょうか。その原因はいくつかありますが、テスト観点リストの作り方、各々のテスト観点の整理の仕方に大きな問題を抱えているケースが多いようです。
具体的に言いますと、テスト設計リストの項目分けに問題があります。
よく見かけるテスト観点リストは「大項目」「中項目」「小項目」といったように、階層構造で整理されていますが、何に大項目を入れるのか、何に中項目を入れるといった、項目分けのルールが不明確で、バラバラになっています。
テスト観点リストの内容が、それほど多くなくて全体が俯瞰できるのであれば、整理が多少 悪くても大きな問題にはならないでしょう。しかし、テスト観点リストの項目が増えてくると、閲覧性がとても重要になってきます。うまく整理されていない数百件以上のテスト観点のリストを見て使えと言われても、手に負えるものではないからです。
うまく整理されていない、すなわち閲覧性が悪いテスト観点リストは、たとえリスト中の個々の内容が良いものであっても、とても使いにくいものになってしまいます。
テストの現場では時間との勝負ですから、必要な情報がすぐに引き出せないテスト観点リストを苦労して読み解くよりも、ハナから自分でテスト設計した方が速い、ということになってしまうわけです。
テスト観点リストの大中小項目を統一しても、解決できない
これまで挙げた問題点を要約すると、以下のようになります。
テスト観点リストを整理する「大項目」「中項目」「小項目」の使い方が設計されていない
↓
テスト観点リストが閲覧しにくい
↓
テスト設計の作業時に、テスト観点リストが使われない
↓
テストのナレッジが共有されず、テストの改善・スキルアップが進まない
では、大中小項目の使い分けを統一したら良いかというと、そういう問題ではありません。
筆者もそれを試みたことがありますが、うまく整理できませんでした。
筆者が見てきたテスト観点リストは、その内容の全部が全部、でたらめになっていたわけではありませんでした。一見、ごちゃごちゃしていてまとまりが無いように見えるテスト観点リストの中から、あるまとまりを抜き出してその部分内を見ると、大中小の項目分けが妥当な形で分類されていました。
しかし、同じテスト観点リスト中の別のまとまりを見ると、そこではまた別のルールで、しかもその部分の範囲内では妥当な形で大中小項目が分けられていました。
このように、テスト観点リストを部分的に見ると統制が取れているものの、全体的に見ると、一つのテスト観点リスト中に大中小項目の使い方のルールがいくつも混在し、その結果、全体的にまとまりが無い、という状態になっていました。
各所でまとめられた観点リストを集めて単純にマージしては、膨大で混沌とした、利用不能なテスト観点リストになってしまいます。そうであれば、テスト観点リストの「大項目」「中項目」「小項目」の使い分けの定義を統一すれば問題解決するのではないかと整理を試みましたが、テストの観点にはさまざまなものがあるため、項目分けのルールを統一するには無理がありました。
要するにやりたいことは、「テスト観点リストをまとめやすくする」「テスト観点リストを閲覧しやすく、利用しやすくする」ということなのですが、これを達成するには、もう一度「テストの観点とは何なのか」というところまで立ち戻る必要がありました。
次章では、テスト観点リストからいったん離れ、改めて、そもそもテストの観点とは何なのか、というテーマで説明を続けます。
テスト観点モデル
本項の冒頭部分で、テストの観点の定義を記載しました。もう一度、以下に引用します。
「ソフトウェアが正しく動作するかを確認するための項目、着眼点、発想の仕方といった、いわばテストを行う上での「切り口」のようなもの」
上記では「テストの切口のようなもの」とありますが、その切り口には色々なものがあります。しかし、その切り口とはどんなものがあるか曖昧で、これが、テスト観点リストがうまく整理できずに混沌としたものになってしまう原因になっているのです。
そこで、「テストの観点」とは何かを改めて整理し、それに基づいてテスト観点リストの構造を再構築するアプローチを取りました。
まず始めに、「テストの観点」とは何かを改めて整理するため、一般的に「テストの観点」と呼ばれているものを列挙し、それらがどのような意味と位置付けを持っているかを分析して項目分け関連付ける形で、「テスト観点モデル」としてまとめました。以下に概念図を示します。
テスト観点モデルは、上記のように、大きく分けて4つの要素で構成されています。
①機能要素
②検証アングル
③テストパラメータ
④確認ポイント
※テスト観点モデルの構成要素は他にもあるのですが、
テスト観点リストの内容を説明するには不要なので、
本稿では割愛しています。
以下、順に内容を説明していきます。
①機能要素
例えば、画面表示テスト、画面遷移テスト、入力確認テスト、接続動作テスト、再生動作テスト、セキュリティテストといったものです。
このように、テスト対象で、検証すべき機能を分解してシンボリックに表すものです。
②検証アングル
例えば、通常バリエーションテスト(正常系テスト)、正常限界値テスト、準正常系テスト、異常系テスト、機能複合・競合テスト(組み合わせテスト)、構成テスト(互換性テスト)、ローカリゼーションテスト、ストレステスト、エージングテスト、性能テスト、ユーザビリティテスト、といったものです。
このように、テストする機能に対し、どんな条件で、どんな特性を検証するかを表すものです。
③テストパラメータ
例えば、入力する文字に対し、どんな文字種を与えるか。(全角・半角・英数字・漢字・記号等。またそれらの偏重(大文字のみ、小文字のみ等)、混在(大文字と小文字の混在)。
例えば、スマートフォンを工場出荷状態にする、メモリフルの状態にする。
例えば、音楽再生直後に曲送りする、音楽再生終了直前に曲送りするなどのイベント。
このように、テストする機能に対し、どんな値や状態を与えるか、どんなイベントを発生させるかといったように、テスト対象にどんなものを"input"するかを表すものです。
④確認ポイント
例えば、画面表示テストであれば、画面表示の構成要素の文言が仕様と不一致のところがあるか、文字切れや文字化けが起きていないか。
例えば、スマートフォン等の動画再生動作テストであれば、動画と音声の同期ズレが起きていないか。
このように、テスト対象が正常に動作しているか、仕様とマッチしていないところは無いか、異常動作するとしたらどんな症状を示すか、といったように、テスト対象の振る舞い(output)のどこを観察するかを表すものです。
テスト観点モデルに基づいた、テスト観点リストの構成
「テストの観点」、すなわち「テストの切り口」にはさまざまなもものがありますが、以上で示しているテスト観点モデルに基づき、以下の4つの区分けで整理できます。
①機能要素
②検証アングル
③テストパラメータ
④確認ポイント
これらはそれぞれ、指しているものが異なっているので、テスト観点リストを「大項目」「中項目」「小項目」で単純に整理するにはそもそも無理があったのです。
では、テスト観点リストはどのように整理したら良いのでしょうか。
筆者は、テスト観点リストを「機能要素+確認ポイント」と「評価アングル+テストパラメータ」の2つのリストに分けて整理しています。以下にイメージ図を示します。
機能要素 | 確認ポイント | |
---|---|---|
確認対象 | 確認内容 | |
画面表示テスト | レイアウト | 画面パーツ(文字、画像、アイコン、スクロールバー等)の配置 |
パース表示 | サイズ、形状、線種、塗りつぶし、グレーアウト | |
文字 | 文言、文字化け、文字切れ、改行崩れ |
テストパラメータ
検証アングル
タイプ
因子
水準
因子
大分類因子
水準
大分類水準
データ
テキスト
文字種
基礎
半角・大文字・英数字
通常バリエーションテスト
特殊
機種依存文字
準正常系テスト
イベント
タッチパネル
タッチ動作
通常
タップ
通常バリエーションテスト
同時
同時タップ
準正常系テスト
このように、「テストの観点」が持つ意味に合わせて項目立てを変えて一覧にすることで、整理しやすく、かつ、閲覧しやすくしています。
終わりに
「テストの観点」は非常に重要な考え方ですが、「テストの観点」という言葉そのものが曖昧である、という面がありました。その曖昧さから、テスト観点リストが整理しにくくて使いにくい、という問題が生じていました。この問題を、テスト観点モデルを導入することで、解決できることを示しました。
テスト観点モデルは、テストに関する過去に得られた知見を再利用しやすくするために作ったものです。
・そのテスト対象の、どの要素をテストするのか (機能要素)
・そのテスト対象を、どんな条件でどんな特性をテストするのか (検証アングル)
・そのテスト対象に、どんな値やイベントを加えるのか (テストパラメータ)
・そのテスト対象の、何を観察するのか (確認ポイント)
テスト観点リストの目的は、本稿の冒頭部分で、テスト設計の効率を上げるため、漏れ抜けを防止するためだと述べました。しかし、テスト観点リストは、そこに書かれている内容を単純にコピペして用いるためのものではありません。
テスト観点リストは、テスト設計で基本的な事項を漏らさないためのベースとして、テスト対象を深く考察するためのガイドとして用いるためにあるのです。
資料ダウンロード
執筆者:堀 明広
バルテス株式会社 第3ソフトウェアテスト事業部 R&C部 部長
組込み系プログラマー、ソフトウェア品質管理を経て、現職はバルテス株式会社 R&C部 部長 兼 上席研究員。担当業務は社内人材育成、検証・分析の技術開発、標準化、セミナー講師。訳書は『ソフトウェアテスト...