RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

デシジョンテーブルについて調べてみた

こんにちは。新卒2年目のbadaikiです。早いもので後輩が配属され、社内の雰囲気がより明るく、より活発になっているように感じます。

目次

はじめに

今回はテスト手法のデシジョンテーブルについて書いていきます。

最近は規模の大きな開発や複雑な仕様の開発を任せていただく機会が増えてきました。そのときに、複数の条件が複雑に絡み合うことによってテストケース作成時に「全パターンを網羅できているのか」が不安になる場面がありました。もちろん100%というのは難しいですが、漏れが起きにくいテストケース、自分が納得のいくテストケースを書くためにはどうすればよいのかを考えました。

まず初めに上記の不安の原因を現状把握も兼ねて分析しました。

  • 同値分割、境界値分析は理解しているつもり(単一の条件なら大丈夫)
  • 完成したテストケースを見て網羅できているのかが読み取りにくい
  • 省略したテストケースが本当に省略してよかったのか不安になる(必要なものを誤って省略していないかな…)

上記のような不安の原因になっているものに対して、何か不足している観点がないか、書き方を工夫することで補えないかと考え調べることにしました。そこで着目したのがデシジョンテーブルでした。

デシジョンテーブルとは

デシジョンテーブルとは、決定表(JIS X 0125)1として規格が定義されています。論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールを組合せます。プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。

以下を仕様としたときのデシジョンテーブルを例にして考えてみます。

ジムの利用料金の仕様

・ クーポン持参の場合は10%OFF
・ 平日なら30%OFF
※ 複数の割引は併用できず、よりお得なものが優先される

f:id:badaiki:20190710111114p:plain:w400
ジム利用料金のデシジョンテーブル

デシジョンテーブルの構成

デシジョンテーブルは以下のような要素で構成されています。

  • 条件記述部(condition stub)

    f:id:badaiki:20190710111221p:plain:w400
    条件記述部
    考慮すべき条件・原因を列挙する部分です。

  • 動作記述部(action stub)

    f:id:badaiki:20190710111308p:plain:w400
    動作記述部

考慮すべき動作・結果を列挙する部分です。

  • 条件指定部(condition entry)
    f:id:badaiki:20190710111347p:plain:w400
    条件指定部

それぞれの条件・原因を特定の値・意味で指定し、ひとつのルールとして関連付けをします。条件指定部には以下のような書き方をします。

表記 ルールで関連付ける意味
Y(Yes) この行に対応する条件・原因が真であることを意味する
N(No) この行に対応する条件・原因が偽であることを意味する
値、語句など この行に対応する条件・原因が記述された値であったり、語句を満たすことを意味する
- この行に対応する条件・原因が無関係であることを意味する
  • 動作指定部(action entry)
    f:id:badaiki:20190710111419p:plain:w400
    動作指定部
    それぞれの動作・結果を特定の値・意味で指定し、ひとつのルールと関連付けをします。条件指定部には以下のような書き方をします。
表記 ルールで関連付ける意味
X(eXecute) この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じることを意味する
- この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じないことを意味する
値、語句など この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が記述された値であったり、語句を満たすことを意味する
  • 規則
    f:id:badaiki:20190710111454p:plain:w400
    規則
    条件・原因の組み合わせと、それに対する動作結果を組み合わせたものです。1つ1つがテストケースになります。

メリット、デメリット

メリット

  • 複数の条件が絡みあった組み合わせを明確にすることができる
  • 網羅率が算出できる( = 実施した規則数 / 全規則数)

デメリット

  • 順序を考慮できない
  • 規則(テストケース)数が爆発的に増加する

例えば仕様に「月曜日なら女性は50%OFF(祝日は除く)」という仕様を追加します。

ジムの利用料金の仕様

・ クーポン持参の場合は10%OFF
・ 平日なら30%OFF
・ 月曜日なら女性は50%OFF(祝日は除く)
※ 複数の割引は併用できず、よりお得なものが優先される

f:id:badaiki:20190708233313p:plain:w600
ジム利用料金のデシジョンテーブル(仕様追加)

すると、途端にケース数が増えることがわかります。ですが、曜日と性別が絡んでいる条件を追加したにも関わらず条件記述部は比較的シンプルなまま維持することができ、さらにテーブルになっているため空でテストケースを並べるよりも網羅性の確認が把握しやすいと感じました。

最後に

今回はデシジョンテーブルについてまとめました。

複数の条件が絡むテストケースでは観点がいくつも存在するため網羅できているのかが不安になります。デシジョンテーブルを利用することで1つ1つの条件に分解し条件記述部を書くことができ、網羅性も確認しやすくなるため有用ではないかと思いました。ただし、テストケースが膨大になってしまうと作業コストがかかってしまうため、1つの画面の一部に用いるなど工夫が必要だと感じました。

テストの精度を高めるために、今後もツールや方法を学習し、実践し努めていきます。

参考にしたサイト

softest.jp www.techscore.com

Copyright © RAKUS Co., Ltd. All rights reserved.