皆さんこんにちは
JPQのBaoです。
皆さんがご存知の通り、同値分割と境界値分析は非常に有用な手法であり、前の記事で見たように、ユーザー インターフェイスで入力フィールドの検証をテストするときに特に役立ちますね。ただし、多くのテストには、ユーザー インターフェイスの下にあるビジネス ロジックのテストも含まれます。今回は、ビジネス ロジックをテストするのによく利用されている「デシジョンテーブル」という手法について、その手法を同値分割、境界値分析と一緒に使い、より強力なテストケースの作り方についてご紹介します。
1. デシジョンテーブルとは
決定表とも呼ばれ、条件（入力）に対して、プログラムがどのように動作（出力）するかを表形式にまとめたものです。
条件（入力）と動作（出力）が複数存在し、また条件によって動作が変わるシステムの場合、その全てのパターンを開発者やテスト担当者の頭の中だけで整理するのは現実的ではありません。一方、デシジョンテーブルを使えば、比較的簡単にそれらを整理してまとめられます。
また、デシジョンテーブルには基本的なフォーマットがあります。
2. デシジョンテーブルの書き方
例えば、次のような仕様が存在するとします。
クレジットカードで決済する際に、以下のバリデーションチェックが入ります。
・実際のアカウントで決済しているか確認し、NGなら決済を承認せずにベンダーへ電話する
・有効のアカウントで決済しているか確認し、NGなら決済を承認せずにベンダーへ電話する
・リミット内の金額で決済しているか確認し、NGなら決済を承認せずにカードホルダーへ電話する
・正常の場所から決済しているか確認し、NGなら決済を承認せずにカードホルダーへ電話する
・上記条件すべてOKなら決済を承認する
この仕様に対してデシジョンテーブルを作成していきましょう！！！
Step1：仕様を分析して、「条件」と「動作」を洗い出す
上記の仕様からみると、以下4つの条件を拾います。
・実際のアカウント
・有効のアカウント
・リミット内の金額
・正常の場所
また、以下3つの動作（結果）を拾います。
・承認
・ベンダーへ電話
・カードホルダーへ電話
Step2：「条件」と「動作」を表に記載する
Step3：条件の全組み合せを記入する
普通は、条件指定部の列数は2の累乗数となり、条件が2つなら4列、3つなら8列、4つなら16列といったように条件の組み合わせの数だけ増えていきます。
条件を満たす場合は「Y」、そうではない場合は「N」が入ります。ここで気を付ける点は、「Y」と「N」の組み合わせを全て表現することです。この組み合わせに漏れがあると、テストケースが網羅できません。では、どうやってパターンが漏れなく記入しますか。
上記表の条件指定部に注目してください。最上位の行は、最もゆっくりと変化します。行の半分は「Yes」、半分は「No」です。2行目は、1行目より少し速く変化しますが、他の全てよりまだゆっくりと変化します。パターンは、4つ「Yes」、また4つ「No」、また4つ「Yes」、また4つ「No」です。最後に、一番下の行では最も速く変化し、パターンは「Yes」、「No」、「Yes」、「No」、「Yes」などです。こういうようなパターン付け方で漏れがなく全ての条件指定が指定できると思います。
Step4：仕様のもとに、条件の組み合わせに対する動作結果を記入する
条件を満たす場合は「X」、そうではない場合は「-」が入ります。
※条件・動作指定部に、いつも「Y」「N」「X」「-」とは限らずに、実際の値を記述することもできます。要するに、パターンが網羅し条件・動作の内容が分かればなんでもOKだと思いますね。
Step5：デシジョンテーブルの圧縮
デシジョンテーブルのなかに、結果が同じ動作になる組合せがある場合、その組合せを一つだけ残して、結果に影響を与えない条件を任意の値を表すマークに置き換えることです。
一番分かりやすいのは、列 9〜16 を 1つの列にすることができますね。
あと、列 1、2、および 3 を見て、列 2 と 3 を一つにすることはできないことに注意してください。なぜならば、 「リミット内の金額？」や「正常の場所？」両方が「-」になってしまうからです。しかし、きちんと仕様を調べると、「カードホルダーへ電話」動作のトリガーするには、これらの条件のいずれかが「No」でないといけないことが分かり、両方が「-」になってはならないわけです。
列3 と4 を一つにするには、リミットがオーバーになったら、決済場所に関係なくカードホルダーへ電話するという意味です。上記と同じく、列7と8も1つにすることはできます。
デシジョンテーブルを圧縮する際に、仕様を注意しながら慎重に進行しなければなりませんね。
また、列の結合するだけではなく、有り得ない組合せを削除することも圧縮の1つの作業です。
ここまで、デシジョンテーブルの作成が完成ですねー
3. デシジョンテーブルテストとは
上記のデシジョンテーブルからテストケースを導出する技法です。
具体的には、前述した「⑤ルール」を、そのままテストケースとして用います。ルールの条件はテストにおける入力、動作は期待結果になります。 すべてのルールをテストする必要があります。
4. 同値分割、境界値分析と一緒に使い
境界値分析などの技法と一緒に使い、テストをする必要がある場合 もあります。
まずは、上記表のルールNo9を見てみましょう。
「どうやって実際のアカウントでないと判断するか」という質問に対して、同値分割を適用すると以下パターンが起こりえるでしょう。
・カードナンバーとカードホルダーが一致しない
・カードナンバーと有効期限が一致しない
・カードナンバーとセキュリティコードが一致しない
・上記の内2 つ (3パターンが存在)
・上記のすべて
では、ルールNo9に対して7つのテストケースが作成できます。
境界値分析はどうですか。上記表のルールNo1〜7を見て、「リミット金額に関するテストケースがいくつあるか」という質問を考えてみましょう。
境界値分析と同値分割を適用すると以下パターンが起こりえるでしょう。
1. 残高がゼロから決済する
2. 決済後、通常の残高になる
3. 決済後、ちょうどリミット金額になる
4. 決済後、ちょうどリミットオーバー金額になる
5. 残高がちょうどリミット金額から決済する（なので、決済するとリミットオーバーになる）
6. 決済後、最大当座貸越値になる (これは実際にあり得ないかもしれないので、テストケース化をしないつもり)
これらをデシジョンテーブルと組み合わせて、最後のテストケースはこんな感じですね。
「リミット内の金額」のすべて同値クラスが成功の決済で表されていることを確認したい場合は、ルールNo1に対して3ケースに分けてより強力なテストを作成できます。
5. 終わりに
ここまでで、デシジョンテーブルテストについて解説してきました。デシジョンテーブルテストは、入力条件の組み合わせに応じて出力結果が変わるような、判定ロジックの部分をテストする場合に利用すると効果的です。また、仕様書の文書が複雑な場合、デシジョンテーブルにすることで思考の整理にもつながりますし、他の人と認識合わせをするツールにも成りえますので、皆さんデシジョンテーブルテストをぜひご活用ください。
最後まで読んでいただき、ありがとうございました！
※参照元
Advanced Software Testing - Vol. 1: Guide to the ISTQB Advanced Certification as an Advanced Test Analyst (Rex Black)