【投稿者】彷徨う饂飩

■　テストの技法

テストをするときによく言われる技法は様々ありますが、以下は代表的なものになります。
　　　・　同値分割
　　　・　境界値分割
　　　・　デシジョンテーブル
　　　・　状態遷移
　　　・　組み合わせテスト
　　　・　探索的テスト
これらのソフトウェアテストを行うときは、テスト仕様書やテストケースを作成します。
※探索的テストの場合は仕様書を作成しないことが多いですが。

■　組み合わせテスト　

上記の各技法のテストケースを作成するとき、おそらく一番頭を悩ませたり数が増えるのが「組み合わせテスト」ではないでしょうか。
組み合わせテストは、「設定項目」と「設定値」を組み合わせてテストケースを作成します。
この「設定項目」「設定値」は、組み合わせ技法では「因子」「水準」ということもあります。
組み合わせテストでは
　　　・　表の列に因子
　　　・　表の行に水準
　　　・　任意のｎ列（ｎ因子）を選んだ時、水準の組み合わせがすべて1回以上現れる
「ｎ因子間網羅」となるテストケースを作成します。

この組み合わせテストのテストケース数、条件によっては結構な数になって時間と人手を圧迫するんですね。
例えば、
　３つのスイッチ（因子）があってそれぞれON/OFF（水準）の状態がある。
この場合、ON/OFFの全組み合わせテスト、全網羅テストケース数は2×2×2　=8ケースとなります。

当然因子と水準が増えればどんどん数は増えていき、時間が足りずテストケースを減らそうにも、さてどれをどう減らす？ということにもなります。

この場合、全組み合わせは　4×4×4　=　64ケースとなる。

■ 経験則による2因子網羅

テストケースを減らすにも裏付けが欲しい・・・という場合、「不具合の多くは、１または２つの因子の組み合わせで発生する」という経験則により、 2因子間の値の組み合わせを網羅する(２因子網羅）分のテストケースを作成する、という考え方があります。
代表的な手法として「直交表」「オールペア法」がありますが、手法より２因子間網羅の考え方について説明させていただきます。

先の「３つのスイッチ」を例に、2因子間網羅でケースを作成すると

というテストケースになり、「わーい、テストケース数が半減した♪」となります。

ですが、
2因子間網羅によるテストケース作成は、テスト漏れリスクVSコストメリット（テストケース数）でもあります。
安易に飛びつき、その結果だけに頼るとテスト漏れによってよりコストがかかることになります。
理想はどうしたって全網羅ではあるのですけれどね‥‥　_(┐ ﾉε|)_ｼﾞｶﾝｶﾞﾅｲﾓﾉﾊﾅｲ

■　２因子間網羅の手法

さて、先ほど「直交表」と「オールペア法」という２因子間網羅のテストケース作成手法を挙げております。 それぞれ突っ込んでいくと複雑になりますが、
直交表：
表３に戻りますと、これはL4直交表と呼ばれるものになります。
「１つの水準に対し、他の因子の水準が組み合わされる回数が同じ」であることを「直交」ということになります。
表３でいえば
　　　・　スイッチ１の水準「ON」に対し
　　　・　他のスイッチ２/３の「ON」と「OFF」が１回ずつ組み合わされている
ことになります。

オールペア法：
どの2因子を選んだとしても、最低1回以上の組み合わせパターンが含まれるというのがオールペア法になります。
表２を例にすると、まずA1の組み合わせで

の組み合わせを作ります。
A2の組み合わせ作成時は、B-Cペアの内容で、Aの組み合わせで実施されているものを除外します 。
　　例）A2-B1-C2を除外し、A2-B1-C3の組み合わせを対象とする
これを繰り返していくことになります。

はい、ここで心の叫びが聞こえます。
「よくわかんない。時間がかかるし、しんどい」
ええ、まったく。よくわかんない、は私の説明下手のせいとしても、手作業でやってると、時間かかるし、なんか漏れそうな気もする・・・。
では、ツールへぶん投げましょう。

EXCELのツールで、「PictMaster]というものが公開されています。
これはMicrosoftのコマンドラインツール「Pict」を使用し、Excel上でオールペア法を行うツールです。
たしか、環境設定で直交法での作成も可能となっています。
クラウド使用に抵抗なければ、GIHOZというサイトの利用もありでしょう。

手法にせよツールにせよ、それをつかうための前準備は十分行わなければなりません。
組み合わせテストの作成を行うまでは
　　　・　開発者・テストケース作成者の十分な打ち合わせ
　　　・　テスト対象の因子・水準の洗い出し
　　　・　そもそも手法を適用すべきか否か。適用するならば何を使うか。
　　　　《手法を適用するならば》
　　　・　手法適用対象となる因子・水準を適切に決定
が必要です。
また、出来上がったテストケースは、必ず精査します。
手作業にせよツールにせよ、実施すべきなのに抜けているケースや、「後から」出てくる組み合わせがあるものです。

■　最後に

くだくだしい内容となってしまいましたが、ここまでお読みいただいた方にお礼を申し上げます。
最後にこれまでの内容と関係は薄いですが、ソフトウェアテストというものについて私見を。
「障害の市場流出」というのは、大きな損害をもたらします。金額的なものさることながら、信頼性は大きく損なわれますし、そうなれば「あー、あれやった会社？んじゃだめ」 ということになります。
ソフトウェアテストは、そのソフトウェアを市場へ出して損害をもたらすことがないかを確認する作業でもあります。
これは、最終段階におけるソフトウェアテストだけではなく、各工程で行わなければなりません。
例えば、製造工程で「この関数を世の中に出しても大丈夫か」は製造された時点で行われなければなりません。
ソフトウェアテストというのも、開発製造の一環であり、各工程の中で組み込まれているものであると意識していただければ幸いです。