テストケースのパターン出し簡易デシジョンテーブル

ソフトウェアの仕様を整理したり、テストパターンを洗い出すとき、皆さんはどうしていますか？

複数の条件が入り組んでいたりしてどう表現するとよいか迷うことがありませんか？

こんなとき、デシジョンテーブルといったものを使うと便利です。

ソフトウェアの動作仕様は、

ある[条件] で [アクション] を行うと [結果] となる。

ということが明らかになっている必要があります。

たとえば、

　[条件] チェックボックスを選択した状態

　[アクション] OKボタンをクリック

　[結果] 確認画面に遷移する

といった具合です。

この [条件] [アクション] [結果] を洗い出し、表に書き出して論理関係を明らかにする。これがデシジョンテーブルの本質です。

ここで解説する簡易デシジョンテーブルはこれをシンプルにしたものですが、実際の業務でこの方法は充分機能しています。

下のニックネーム登録画面の簡易デシジョンテーブルを作ってみましょう。

ニックネームは半角英数のみを許し、それ以外の場合はエラーメッセージを表示するという仕様とします。

画面には以下が含まれています。

簡易デシジョンテーブルは以下のようになります。

テストケースのパターンを#1〜#6まで定義してみました。縦に見て、[条件] [アクション] [結果] に○がついているものを確認していきます。

たとえば#1のテストケースは、

　[条件] ニックネーム入力ボックスに任意の文字列が入力されている

　[条件] 利用規約同意のチェックボックスがチェックされている

　[アクション] 登録ボタンをクリックする

　[結果] 登録確認画面に遷移する

というテストケースということです。

いかがでしょうか？

テストケースを明確にするということは、同時に仕様を明確にして整理することとつながっています。このようなやり方で、わかりやすく表現することはとても重要です。

今回の説明は、あくまで一例です、いろいろと工夫してみてください。（ただし、あまり複雑にしないことを推奨しています）

ソフトウェア開発の現場がより良くなることを願ってます！

今回のケースは、全ての条件・アクションの組み合わせを網羅したパターンになっていないことに気がつきましたでしょうか？

例えば、ニックネームが未入力で利用規約が未チェックで登録ボタンがクリックされた場合、エラーは何が出るのか？両方出るのか？ちゃんとでるのか？・・といったことはテストされませんね。

これを「漏れ」と判断するかどうかはさておき、このようにテーブルに表すことで、何をやり、何をやっていないかということがよりわかりやすくなります。

実際には、全ては網羅しなくていいけど、ここまではやっておこう、とか、これとこれだけの組み合わせは網羅しておこうみたいな話ができるわけです。

したがって、一般に全ての組み合わせを網羅したテストを行うことは現実的ではないのです。テストをどこまでやるかは、トレードオフになります。

もし全てのパターンを網羅しようとすると、そのパターン数が膨大になってしまう問題があります。（組み合わせ数の爆発問題）

この組み合わせ問題を「いい感じに」間引いてテストパターンを洗い出す手法があります。All-Pair法、直交表など呼び方が色々ありますが、組み合わせテストの技法です。これらはとても良くできていて面白いです。是非やってみることをお勧めします。

実際にデシジョンテーブルを作ってみると、単にテスト項目の抜け漏れに気付きやすくなるだけではなく、「あれ？この仕様どうなっているんだっけ？」といったそもそもの仕様の不足や矛盾に気がつけることも多いです。

「どういうテストをするか」という検討は、できるだけ早い段階で作ることをお勧めします。１番のお勧めは、先にテスト仕様を作ってから作るということです。（テストファースト）