テスト設計の基礎

本記事では、テスト基本設計2番目の工程である、テストマップについて解説します。

テストマップ作成の工程では、最初の工程で作成したテスト設計仕様書を基にしてテストマップを作成していくこととなります。

テストマップを作成する目的、役割、作成方法や、次の工程である機能動作確認一覧との繋がりについて、本記事にて詳しく解説していきます。

【目次】
１．テストマップとは
２．テストマップの必要性
３．テストマップの書き方
４．テストマップを書くときのコツ
５．おわりに

1.テストマップとは

テストマップとは、テスト設計仕様書でまとめた、機能一覧と観点一覧を組み合わせて表にしたものです。ただし、ただ組み合わせるだけではなく、各組み合わせに対してテストの重要度を定めていきます。

※機能一覧、観点一覧については、「テスト設計仕様書」をご参照ください。

テスト設計仕様書では、テスト計画書で定義されたテスト対象機能と観点を細分化することで、テスト対象となる機能と観点を明確にしました。
テストマップでは、この細分化した機能と観点を組み合わせることで、各機能に対してどのような観点のテストをどのぐらい重点的に行うのかを定義していきます。

2.テストマップの必要性

QUINTEEで、このようなテストマップを作成する目的は大きく2つです。

1つは、「テストの全体像が分かるようにするため」です。
テストマップを作成すると、「どの機能に対してどの観点がテストできるのか、テストできないのか」が明らかになります。これにより、テストの抜け漏れを防ぐことができます。

テストの対象となる機能はすべて同じ観点でテストできるわけではありません。機能ごとにテストできる観点は異なります。

例えば、メッセージテキストとボタンのみが表示されたWebサイトの画面をテストする場合、文字入力のテストは行えません。

テストマップで機能と観点を組み合わせずにテストケースを作ろうとすると、おそらくテストケースを作りながら、「この機能は、この観点でテストできる、この観点ではテストできない」というように、機能と観点の組み合わせを都度考えていくことになると思います。これでは、テストケースが出来上がった後に、仮に特定の観点のテストケースが無かった場合、その理由が「テストできない観点だから」だったのか、「観点を考えるのが抜けてしまっていた」からなのかがわかりません。テストの抜け漏れにつながる危険性が高いです。

テストマップでは、抽出した機能と観点を全て組み合わせていきます。1つ1つテストできるかどうかを記載していくため、機能と観点の組み合わせの抜け漏れを防ぐことができるのです。

続いて2つ目の目的は、「どの機能とどの観点の組み合わせを重点的にテストすべきかを明確にするため」です。

ソフトウェアが大規模化、複雑化した昨今では、限られたリソース（納期、時間、予算）の中ですべてをテストすることはほぼ不可能です。すべてのテストはできないのに、重点的にテストすべき箇所を明確にしないままテストケースを作ってしまうと、「作成したテストケースはスケジュール内に全て実施できるのか」、「どのテストケースを優先して実施すべきなのか」がわかりません。リソースとのバランスが合わない量のテストケースや、不要なテストケースが出来上がってしまう危険性があります。

テストマップを作成し、テストの重要度を設定すれば、「テストの重要度が高い箇所は重点的にテストして、テストの重要度が低い箇所は最低限のテストのみに留める」など、リソースに収まる範囲でテストできるように調整することができます。そうすることで、リソースが限られている中でも十分にテストできるかどうかが判断できるようになるのです。

このように、テストマップを作成すると、「テストの抜け漏れを防止できる」、「十分にテストできるかどうかが判断できる」といった効果があります。そのため、QUINTEEでは、テストマップを作成しているのです。

ちなみに、テストマップは他の場面でも役立つことがあります。それは、「関係者へテスト範囲を説明する時」です。テストマップは「テストの全体像」、「重点的にテストすべき箇所」が把握できるように視覚化されています。つまり、テストマップを使うことでテスト実施範囲の伝達が容易になり、説明を聞く側の理解も早まるでしょう。

3.テストマップの書き方

このように、テスト設計において大きな助けとなるテストマップ、皆さんも実際に作成してみましょう。テストマップを作成するために特別なツールを準備する必要はありません。Excelがあれば作成できます。

まずは、「テスト設計仕様書の作成」で、作成したテスト設計仕様書を用意しましょう。前述したように、テスト設計仕様書にまとめた機能一覧と観点一覧を使います。

次にテストマップのベースを用意します。
テスト設計仕様書にまとめた機能一覧、観点一覧を縦と横に並べられるように、枠を作成しましょう。

※Qbook アカデミーでは、QUINTEEで使用している各種ドキュメントのテンプレートをダウンロードすることができます。
　テストマップについては、下記リンクからダウンロードできますので、こちらを使用して頂くのも良いかと思います。

枠が用意できましたら、機能一覧と観点一覧を縦と横に並べてみましょう。

次に、並べた機能と観点の交わる箇所に、「テストが実施できるか/実施できないか」、「テストが実施できるのであればテストの重要度はどのぐらいか」を記載していきます。

テストの重要度は機能の重要度と観点の重要度から決定します。
下図のような凡例を作り、凡例に沿って入力していきましょう。

※機能の重要度と観点の重要度についても、「テスト設計仕様書の作成」で解説しています。本記事での説明は割愛しますので、そちらをご参照ください。

私たちバルテスが使っている凡例では、重要度を「A」、「B」、「C」の3段階、テストが実施できない箇所を「-」、テストは実施できるが、テストしない方針とした箇所を「NT」で表しています。

現場によって記載すべき情報は異なると思いますので、凡例は現場に合う形のものを各々で作成すれば良いかと思います。

※テストする機能と観点が膨大で、重要度を１つ１つ設定していくのは大変という方は、「○」と「△」を使用して、テストを実施するかどうかだけでもまとめてみましょう。これだけでも、テストを実施すべき範囲は明らかになるため、効果があります。

「作りたいけど、忙しくて時間がないから作れない」と諦めるのではなく、忙しくて時間がないときこそ、簡易的な形でも良いのでテストマップを作成し、設計するテストケースの内容を見誤らないようにしましょう。

4.テストマップを書くときのコツ

機能一覧と観点一覧を並べて、テストの重要度を入力していくと、「機能と観点の重要度がそれぞれ違う箇所のテスト重要度はどうやって決めるの？」という疑問が出てくるかと思います。

このような場合は、事前に重要度設定目安を定めておきます。
下図のように、機能と観点の重要度ごとにテストの重要度は何を設定するのか決めておきましょう。

ただし、テスト計画で立てた方針によっては、定めた目安よりもテストの重要度が高く（低く）なる場合もあるかと思います。
そのような場合は、テストマップの下部に特記事項欄を用意して、テストの重要度に対するコメントを記録できるようにしておくと良いでしょう。

5.おわりに

テストマップにて、機能と観点とを組み合わせて、テストの重要度を決めることで、テストの全体像が見えてきました。
テスト詳細設計作成の工程では、機能に組み合わせた観点を具体的にしていくのですが、このままではまだできません。

なぜならば、開発されるシステムやソフトウェアは、まだ世の中には無い独自の機能が搭載されていることがほとんどです。そのような機能をテストするためには、テスト設計仕様書で作成し、テストマップで使用した観点一覧では十分とは言えません。この観点一覧は様々なテスト対象で適用できるように意図的に汎用的にしたものであるためです。

独自の機能を十分にテストするためには、そのための観点を別途抽出し、まとめる必要があります。その作業を行うのが、次の工程である、機能動作確認一覧です。

テストマップが作成できるようになりましたら、次はテスト基本設計3番目の工程である機能動作確認一覧の作成に進みましょう。