以前の記事にて、テストプロセスの解説をし、どのようなテストの作業があるのかを示しました。今回からは、その中の「テスト設計」作業に用いられるテスト設計技法を解説します。全５回の解説の初回となる今回はどのような技法があるのかを紹介し、以降の紹介で具体的な技法の解説を行います。

1.技法の分類

具体的なテスト設計技法の話に入る前に、まずは技法の分類について考えます。テスト設計技法にはさまざまな分類方法がありますが、ここでは代表的な3つの分類方法を紹介します。

1.1 目的による分類

代表的な分類方法のひとつとして、「目的」による分類があります。効果的かつ無駄のないテストのために、テスト設計では以下の3つの目的を実現する必要があります。

1. テスト対象の振る舞いのパターンを網羅するようにテスト設計をする
2. テスト対象をなるべく少ないテストケースでテストができるようテスト設計をする
3. なるべくたくさんのバグを発見できるようテスト設計をする

テスト設計技法は上記の目的のいずれかを実現するために考案されたものであり、したがってどの目的を実現するかで分類をすることができます。本連載では簡単のため、この3つの分類を以下のように呼ぶこととします。

1. 網羅型
2. 削減型
3. 標的型

1.2 観点による分類

もうひとつの代表的な分類方法として、技法が「ブラックボックス型」と「ホワイトボックス型」があります。

ブラックボックス型の技法は、ソフトウェア自体の構造は考慮せず（＝ブラックボックスとして扱い）、ソフトウェアがどう振る舞うべきかどうかを規定した仕様に着目して、そこからテストケースを作成する技法のことです。一方ホワイトボックス型の技法は、ソフトウェア自体の構造に着目してデータの流れや制御が 正しいかどうかを確認するテストケースを作成する技法をいいます。

ただし、現実的には純粋にブラックボックス型、もしくはホワイトボックス型のみの観点でテストケースを作成することは稀であり、両者の観点を組み合わせた 「グレーボックス型」となることが多いです。しかし本連載では簡潔に紹介するため、技法はブラックボックス型とホワイトボックス型のいずれかに分類できるものとして解説を行います。

1.3 ISTQBでの分類

前節ではブラックボックス型とホワイトボックス型のテスト設計技法を紹介しましたが、ISTQBではこれに加えて「経験ベース型」の技法が定義されています。

熟練したテストエンジニアはソフトウェアの仕様や実現方式などから、どのようなバグが発生しやすいかをある程度想定し、それらをピンポイントで狙いにいくことができます。また、機能拡張を繰り返しているソフトウェアであれば、過去のバグの履歴などから起こり得るバグをある程度容易に想定することが可能です。近年、こういった経験やノウハウなどに基づいたテスト設計技法が体系化されてきており、これらをブラックボックス型とホワイトボックス型に分類するのは困難であるため、新たに経験ベース型という形で分類するようになりました。

なお、前節に比べて新しいカテゴリが増えただけであり、ブラックボックス型とホワイトボックス型の定義は変わっていません。

2.本連載で紹介する技法

以下に、本連載で具体的に紹介する技法を、目的による分類とISTQBでの分類を軸にして整理した表を示します。各分類の冒頭の数字は何回目の連載で紹介するかを表しています。（本記事は(1)にあたります。）

同値分割や境界値分析を、厳密にブラックボックス型かホワイトボックス型かを議論するのは難しいことです。一般的にはブラックボックス型のテストに分類されることが多い（実際には、ホワイトボックス型テストを提供しているときでも、入力データの洗い出しなどの際に利用されます）ため、本連載でもそのように扱います。

今回はテスト設計技法の分類について解説しました。技法自体について学ぶことも大事ですが、その技法がどういう性質をもっており、またどういう目的を実現するものかを理解しておくことも非常に重要です。これをしっかりと念頭におくことで、次回以降で解説する具体的なテスト設計技法がより理解しやすくなります。

参考文献：
テスト技術者資格制度 Foundation Level シラバス 日本語版
© International Software Testing Qualifications Board VER2011
© 日本語翻訳版Japan Software Testing Qualifications Board Version 2011.J02

Tweet