2024.02.07
テストエンジニアが適切なテスト設計を行う際の気を付けるべきポイントとして、「実施すべきテストの抜け漏れがないか」と「適切な箇所に必要数のテストケースを作成しているか」の2つが挙げられます。
それらをチェックすることができる手法が「テストマップ」です。
今回の記事では、テストマップを作成する目的、役割、作成方法や、次の工程である機能動作確認一覧との繋がりについて、詳しく解説していきます。
1．テストマップとは
テストマップとは、テスト設計仕様書でまとめた、機能一覧と観点一覧を組み合わせて表にしたものです。
ただし、単に組み合わせるだけではなく、各組み合わせに対してテストの重要度を定めていく必要があります。
※機能一覧、観点一覧については、「テスト設計仕様書」をご参照ください。
テスト設計仕様書では、テスト計画書で定義されたテスト対象機能と観点を細分化することで、テスト対象となる機能と観点を明確にしました。
テストマップでは、この細分化した機能と観点を組み合わせることで、各機能に対してどのような観点のテストをどのぐらい重点的に行うのかを定義していきます。
2．テストマップの目的・必要性
QUINTEEで、このようなテストマップを作成する目的は大きく2つです。
- テストの全体像が分かるようにするため
- どの機能とどの観点の組み合わせを重点的にテストすべきかを明確にするため
それぞれ解説していきます。
テストの全体像が分かるようにするため
1つは、「テストの全体像が分かるようにするため」です。
テストマップを作成すると、「どの機能に対してどの観点がテストできるのか、テストできないのか」が明らかになります。これにより、テストの抜け漏れを防ぐことができます。
テストの対象となる機能はすべて同じ観点でテストできるわけではありません。機能ごとにテストできる観点は異なります。
例えば、メッセージテキストとボタンのみが表示されたWebサイトの画面をテストする場合、文字入力のテストは行えません。
テストマップで機能と観点を組み合わせずにテストケースを作ろうとすると、おそらくテストケースを作りながら、「この機能は、この観点でテストできる、この観点ではテストできない」というように、機能と観点の組み合わせを都度考えていくことになると思います。
これでは、テストケースが出来上がった後に、仮に特定の観点のテストケースが無かった場合、その理由が「テストできない観点だから」だったのか、「観点を考えるのが抜けてしまっていた」からなのかがわかりません。テストの抜け漏れにつながる危険性が高いです。
テストマップでは、抽出した機能と観点を全て組み合わせていきます。1つ1つテストできるかどうかを記載していくため、機能と観点の組み合わせの抜け漏れを防ぐことができるのです。
どの機能とどの観点の組み合わせを重点的にテストすべきかを明確にするため
続いて2つ目の目的は、「どの機能とどの観点の組み合わせを重点的にテストすべきかを明確にするため」です。
ソフトウェアが大規模化、複雑化した昨今では、限られたリソース（納期、時間、予算）の中ですべてをテストすることはほぼ不可能です。すべてのテストはできないのに、重点的にテストすべき箇所を明確にしないままテストケースを作ってしまうと、「作成したテストケースはスケジュール内に全て実施できるのか」、「どのテストケースを優先して実施すべきなのか」がわかりません。リソースとのバランスが合わない量のテストケースや、不要なテストケースが出来上がってしまう危険性があります。
テストマップを作成し、テストの重要度を設定すれば、「テストの重要度が高い箇所は重点的にテストして、テストの重要度が低い箇所は最低限のテストのみに留める」など、リソースに収まる範囲でテストできるように調整することができます。そうすることで、リソースが限られている中でも十分にテストできるかどうかが判断できるようになるのです。
このように、テストマップを作成すると、「テストの抜け漏れを防止できる」、「十分にテストできるかどうかが判断できる」といった効果があります。そのため、QUINTEEでは、テストマップを作成しているのです。
ちなみに、テストマップは他の場面でも役立つことがあります。それは、「関係者へテスト範囲を説明する時」です。テストマップは「テストの全体像」、「重点的にテストすべき箇所」が把握できるように視覚化されています。つまり、テストマップを使うことでテスト実施範囲の伝達が容易になり、説明を聞く側の理解も早まるでしょう。
3．テストマップの書き方
テスト設計において大きな助けとなるテストマップは、作成するために特別なツールを準備する必要はありません。Excelがあれば作成できます。
まずは、「テスト設計仕様書の作成」で、作成したテスト設計仕様書を用意しましょう。前述したように、テスト設計仕様書にまとめた機能一覧と観点一覧を使います。
次にテストマップのベースを用意します。
テスト設計仕様書にまとめた機能一覧、観点一覧を縦と横に並べられるように、枠を作成しましょう。
枠が用意できましたら、機能一覧と観点一覧を縦と横に並べてみましょう。
次に、並べた機能と観点の交わる箇所に、「テストが実施できるか/実施できないか」、「テストが実施できるのであればテストの重要度はどのぐらいか」を記載していきます。
テストの重要度は機能の重要度と観点の重要度から決定します。
下図のような凡例を作り、凡例に沿って入力していきましょう。
※機能の重要度と観点の重要度についても、「テスト設計仕様書の作成」で解説しています。本記事での説明は割愛しますので、そちらをご参照ください。
まとめ
テストマップにて、機能と観点とを組み合わせて、テストの重要度を決めることで、テストの全体像が見えてきました。
テスト詳細設計作成の工程では、機能に組み合わせた観点を具体的にしていくのですが、このままではまだできません。
なぜならば、開発されるシステムやソフトウェアは、まだ世の中には無い独自の機能が搭載されていることがほとんどです。そのような機能をテストするためには、テスト設計仕様書で作成し、テストマップで使用した観点一覧では十分とは言えません。この観点一覧は様々なテスト対象で適用できるように意図的に汎用的にしたものであるためです。
独自の機能を十分にテストするためには、そのための観点を別途抽出し、まとめる必要があります。その作業を行うのが、次の工程である、機能動作確認一覧です。
テストマップが作成できるようになりましたら、機能動作確認一覧の作成に進みましょう。
