こんにちは。新卒2年目のbadaikiです。早いもので後輩が配属され、社内の雰囲気がより明るく、より活発になっているように感じます。
目次
はじめに
今回はテスト手法のデシジョンテーブルについて書いていきます。
最近は規模の大きな開発や複雑な仕様の開発を任せていただく機会が増えてきました。そのときに、複数の条件が複雑に絡み合うことによってテストケース作成時に「全パターンを網羅できているのか」が不安になる場面がありました。もちろん100%というのは難しいですが、漏れが起きにくいテストケース、自分が納得のいくテストケースを書くためにはどうすればよいのかを考えました。
まず初めに上記の不安の原因を現状把握も兼ねて分析しました。
- 同値分割、境界値分析は理解している
つもり(単一の条件なら大丈夫) - 完成したテストケースを見て網羅できているのかが読み取りにくい
- 省略したテストケースが本当に省略してよかったのか不安になる(必要なものを誤って省略していないかな…)
上記のような不安の原因になっているものに対して、何か不足している観点がないか、書き方を工夫することで補えないかと考え調べることにしました。そこで着目したのがデシジョンテーブルでした。
デシジョンテーブルとは
デシジョンテーブルとは、決定表(JIS X 0125)1として規格が定義されています。論理関係を表形式で整理するためのツールで、行方向に条件と動作、列方向にルールを組合せます。プログラムの処理条件やポリシーなどをわかりやすく表現するために利用したり、ソフトウェアのテスト条件を整理するためにも利用されます。
以下を仕様としたときのデシジョンテーブルを例にして考えてみます。
ジムの利用料金の仕様 ・ クーポン持参の場合は10%OFF ・ 平日なら30%OFF ※ 複数の割引は併用できず、よりお得なものが優先される
デシジョンテーブルの構成
デシジョンテーブルは以下のような要素で構成されています。
条件記述部(condition stub) 考慮すべき条件・原因を列挙する部分です。
動作記述部(action stub)
考慮すべき動作・結果を列挙する部分です。
- 条件指定部(condition entry)
それぞれの条件・原因を特定の値・意味で指定し、ひとつのルールとして関連付けをします。条件指定部には以下のような書き方をします。
表記 | ルールで関連付ける意味 |
---|---|
Y(Yes) | この行に対応する条件・原因が真であることを意味する |
N(No) | この行に対応する条件・原因が偽であることを意味する |
値、語句など | この行に対応する条件・原因が記述された値であったり、語句を満たすことを意味する |
- | この行に対応する条件・原因が無関係であることを意味する |
- 動作指定部(action entry) それぞれの動作・結果を特定の値・意味で指定し、ひとつのルールと関連付けをします。条件指定部には以下のような書き方をします。
表記 | ルールで関連付ける意味 |
---|---|
X(eXecute) | この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じることを意味する |
- | この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が生じないことを意味する |
値、語句など | この列に指定された条件・原因の真偽値にすべて適合する場合、この行に対応する動作・結果が記述された値であったり、語句を満たすことを意味する |
- 規則 条件・原因の組み合わせと、それに対する動作結果を組み合わせたものです。1つ1つがテストケースになります。
メリット、デメリット
メリット
- 複数の条件が絡みあった組み合わせを明確にすることができる
- 網羅率が算出できる( = 実施した規則数 / 全規則数)
デメリット
- 順序を考慮できない
- 規則(テストケース)数が爆発的に増加する
例えば仕様に「月曜日なら女性は50%OFF(祝日は除く)」という仕様を追加します。
ジムの利用料金の仕様 ・ クーポン持参の場合は10%OFF ・ 平日なら30%OFF ・ 月曜日なら女性は50%OFF(祝日は除く) ※ 複数の割引は併用できず、よりお得なものが優先される
すると、途端にケース数が増えることがわかります。ですが、曜日と性別が絡んでいる条件を追加したにも関わらず条件記述部は比較的シンプルなまま維持することができ、さらにテーブルになっているため空でテストケースを並べるよりも網羅性の確認が把握しやすいと感じました。
最後に
今回はデシジョンテーブルについてまとめました。
複数の条件が絡むテストケースでは観点がいくつも存在するため網羅できているのかが不安になります。デシジョンテーブルを利用することで1つ1つの条件に分解し条件記述部を書くことができ、網羅性も確認しやすくなるため有用ではないかと思いました。ただし、テストケースが膨大になってしまうと作業コストがかかってしまうため、1つの画面の一部に用いるなど工夫が必要だと感じました。
テストの精度を高めるために、今後もツールや方法を学習し、実践し努めていきます。
参考にしたサイト
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください!
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com