みなさん、こんにちは。
テスト仕様書の作り方大公開の第４回です。第２回の記事中の『パターン分けが必要か考える』で、「確認項目欄の内容を確認するうえで条件やデータのバリエーションによる処理の分岐（結果の違い）があるかどうかによって、パターン分けをする（デシジョンテーブルを作る）かそうでないかを決めます。」ということになっていたと思います。 そこで、今回はデシジョンテーブルの作り方及びパターン番号、パターン説明の書き方についてご紹介します。
前回記事はこちら
同じようでも使い回しはダメ！
デシジョンテーブルを作るかどうかについては決まり事や基準があるわけではないのですが、一般に3通り以上のバリエーションがある、または、複数の条件が関与する場合はデシジョンテーブルを作成すべきです。 2通りの場合はどちらでもかまいませんが、バリエーションが増える可能性があるならばデシジョンテーブルを作った方がよいでしょう。
テスト条件一覧でパターン分けをする（デシジョンテーブルを作る）項目については識別するためのパターン番号を付けて、パターン説明に「何のパターンなのか」を簡潔に書きます。 実際にやってみた例を図-1に示しますので参考にしてください。
ここで注意すべき点は、同じようなものだからといってパターン番号を同じにして共通にしてはいけないということです。なぜなら、例えば氏名（漢字）にも氏名（カナ）にも文字種・文字数のパターンを作ることになりますが、それぞれ条件の内容や入力値・結果のバリエーションが異なるからです。
これが曖昧さを排除する工夫だ
デシジョンテーブルについて、まずは図-2のフォーマットをご覧ください。一般的な教科書に出てくるデシジョンテーブルとは少し違うなと思われることでしょう。
一般的なデシジョンテーブルが図-3で、私たちのお勧めが図-4になります。どちらも[条件記述部][条件指定部][動作記述部][動作指定部]の4つの部分から成り立っている点では変わりありません。 違いを説明しますと、[条件記述部] を「因子」と「水準」に、[動作記述部]を「確認項目」と「期待値」に分けていることです。 ※「因子」とは条件を左右する要因、「水準」とは各因子に設定する段階（取りうる値）のことをいいます。
このような書き方をすると、画面やDBのどの項目なのか？具体的にどの値なのか？といった条件や動作が具体的に記述できるようになります。つまり、入力条件の「どの項目がどういう値の時」と、出力結果の「どの項目がどういう値になるはず」が具体的に表現できます。 その結果、テストケースの曖昧さが排除できるとともに、テストデータを作成するときにどんな値が必要か明確になるというメリットがあるのです。
次回（第５回）は実際にデシジョンテーブルの各項目を記述していきます。お楽しみに。
ご愛読、ありがとうございました。
テストに関するお役立ち資料
テスト設計・仕様書の作り方に役立つ資料を多数ご用意しています。ぜひDLしてご利用下さい。
資料一覧は【こちら】
