テスト技法ポジショニングマップ
テスト技法の位置づけを明らかにすることを目的とした図です。
テスト技法ポジショニングマップの目的
本ポジショニングマップは、様々なテスト技法がみな有効でカバーしあっていることを示すことを目的としています。
※ 本マップで取り上げるテスト技法は、機能性と信頼性の評価を目的としたものを対象としています。したがって、非機能要件のテストとセキュリティテスト、テスト分析のための技法（NGTやマインドマップ）はスコープ外です。
※ もちろん、これが、唯一の正解とは思っていません。 おかしなところや増やしたい技法がありましたらメールください。
横軸の説明
横軸は、「ピンポイント←→網羅的」となっています。
ピンポイントとは、狙い撃ちをするテストという意味です。絵にあるように究極のピンポイントは一本釣りです。魚（バグ）があるところを狙うためには、ソースコード上で特別な処理を行っている定数（異常値・特異値）を狙ったり、過去の経験から「このようなエラーが起こるはずだ」と仮説を立てて推測するといったことをします。また、過去の経験をもとにせずに、静的解析を実施し、複雑度その他の値からバグが潜んでいそうなモジュールを集中的にテストするといったこともします。
その他に、リスクを評価し、テストの重点を絞ったり、テスターが実際に触りながら、または、お客様が業務を流しながらバグを見つけるテストもピンポイントと言えるでしょう。
網羅的とは、「何らかのテストモデルを立てて、そのモデルの網羅性をとりながら実施するテスト」のことを指します。コードカバレッジなどは一番分かりやすい例でしょう。網羅的テストの多くには網羅の深さというものがあり、お客様の求める品質に応じて深くテストします。ただし、深すぎるとテストケース数が爆発し、自動化をしないとテストしきれなくなります。この辺の効果と効率のバランスを取ることが実際のテストにおいては重要な戦略ポイントとなります。
縦軸の説明
縦軸は、「White Box←→Black Box」と「設計－仕様－要件－顧客要求」が重なっています。
ソースコード（プログラミングコード）を元にテスト設計を実施するテストをWhite Boxテストと呼びます。対照的に、ソースコードを見ずに主にソフトウェアシステムの入出力に着目しテスト設計をしていく方法がBlack Boxテストです。
その中間というよりもBlack Boxテストの一種として必要に応じてソースコードを見ることも厭わないテストのことをGray Boxテストと呼びます。たとえば、処理の流れの順番や、境界値などをソースコードによって把握するテストです。
テスト設計は何らかのソフトウェア成果物をもとに行います。設計に対して実施するテストはテストプロセスの初期に実施すべきでしょうし、顧客要求に対する妥当性確認は最後のフェーズに実施するのが効果的です。
この軸はVモデルの縦軸と対応しています。
活用方法
色々な活用方法が考えられると思いますが、以下にいくつかアイデアを書きます。
テスト技法の抜けの確認
テスト技法を使用する順番
お客様とのテスト戦略レビュー
テストの自動化をする際の参考に使用する
※ 活用に当たっては、各テスト技法の位置、大きさ、重なり具合を対象ソフトウェアに合わせて修正することが有効です。
オリジナルファイル
Microsoft PowerPoint形式の【
ファイル】
※ 上記ファイルを利用するための許可申請は一切不要ですが、修正されたり別の軸によるマップが増えることがあるので、ここのURLを書いておいていただけると幸いです。
謝辞
本ポジショニングマップ作成に当たっては、次の方に有益なコメントを頂きました。
おかげさまで、
最初のバージョンから、大幅に修正＆改良することができました。どうもありがとうございました。
湯本 剛 氏
鈴木 三紀夫 氏
大西 建児 氏
太田 健一郎 氏
本田 和幸 氏
来間 啓伸 氏
加瀬 正樹 氏
山根 慎之介 氏
西原 留美奈 氏
増田 聡 氏
※ 上記リストはコメントを頂いた順です。