はじめに
この記事ではデシジョンテーブルを用いたテスト設計(テストケース作成)についてざっくりに説明します。
業務で開発と同時にテストケースの作成を任されることが増えてきました。
観点だけを箇条書きで書き出して組み合わせを考え作成していましたが、
パターンに考慮漏れが起こること、今回のテストでは全部でどのくらいのテストケースで網羅できるのかが不明瞭なため、デシジョンテーブルを用いてテストケース作成をするようにしました。
デシジョンテーブルの存在は知っていたのですが、しっかり理解しておらず活用できずにいました。
理解するのは難しくなく、効率的に網羅性の高いテストケースを作成することが可能になり、
全てのケースをデシジョンテーブルで可視化して見通せるので資料としても有用なものになると思います。
デシジョンテーブルとは
- 論理関係を表形式整理するために使用する
- 行方向に条件と動作を記載し、列方向にルールを記載して組み合わせる
- 決定表(JIS X 0125)としてJISで規格が定義されている表
文章だけではよく分からないので,
下記の仕様の時のテストケースをデシジョンテーブルで表します。
仕様
映画館のチケット料金
・割引券提示の場合は10%OFF
・平日は20%OFF
※割引の併用は不可
※割引条件が重なる場合は割引率の高い方が適用される
デシジョンテーブル
デシジョンテーブルの構成要素
条件記述部(condition stub)
考慮すべき条件・原因を列挙する部分。
動作記述部(action stub)
考慮すべき動作・結果を列挙する部分。
条件指定部(condition entry)
条件・原因を特定の値や意味で表現して、ルールとして関連付けます。
条件指定部での書き方は下記。
| 表記 | 意味 |
|---|---|
| Y(YES) | 行に対する条件・原因が真であることを表す |
| N(No) | 行に対する条件・原因が偽であることを表す |
| 値や語句など | 行に対する条件・原因が記載された値や語句となることを表す |
| - | 行に対する条件・原因が無関係であることを表す |
-
動作指定部(action entry)
動作・結果を特定の値や意味で表現して、ルールとして関連付けます。
動作指定部での書き方は下記。
| 表記 | 意味 |
|---|---|
| X(eXecute) | 列に指定された条件・原因の真偽値に全て適合する場合に、行に対する動作・結果が生じることを表す |
| - | 列に指定された条件・原因の真偽値に全て適合する場合に、行に対する動作・結果が生じないことを表す |
| 値や語句など | 列に指定された条件・原因の真偽値に全て適合する場合に、行に対する動作・結果が記載された値や語句となることを表す |
-
規則
条件・原因の組み合わせ & 対応する動作結果の組み合わせ。
規則の1つ１つがテストケースとなります。
「平日で割引券提示の場合→割引率は20%」
テストカバレッジ(網羅率)も
実施した規則数 / 全規則数で簡単に算出できます。
まとめ
このようにデシジョンテーブルを使うことで、
全てのパターンを洗い出して網羅的なテストケースを作成することができます。
途中で仕様が追加になった場合も、条件記述部と動作記述に追加すれば簡単にテストケースの追加ができます。
反面、ケースがどんどん増加してしまいます。
網羅性が高い故に、テストケース数が多くなってしまう部分があるので、本当に実施が必要なテストなのかは見極める必要があります。
視覚的にも組み合わせが把握しやすいので、観点が多く複雑な条件が絡むテスト設計の際には
是非デシジョンテーブルを活用してみてはいかがでしょうか。
最後まで読んで頂きありがとうございます。