爆発しがちなデシジョンテーブルを抑え込むちょっとしたコツ

今回はテストの小ネタということで、爆発しがちなデシジョンテーブルを抑え込むちょっとしたコツです。ソフトウェアテストの小ネタの12/14担当です。

ソフトウェアテストの小ネタ Advent Calendar 2020 - Qiita

爆発しがちな例

Aサーバー（以下A）からBサーバー（以下B）にデータをコピーする機能の例を考えます。コピーボタンが押下可能な条件は下記とします。

Aにデータが存在する
Bにデータが存在しない
Aのコピー可能設定がtrueである
Bのコピー可能設定がtrueである
Aサーバーの状態がノーマル状態、またはメンテナンス状態である
Bサーバーの状態がノーマル状態、またはメンテナンス状態である

※状態はノーマル、メンテナンス、セーフモードの3つ

さて、これをデシジョンテーブルにすると2×2×2×2×3×3で144パターンになります。デシジョンテーブルはちょっとパラメータが増えると、すぐ爆発してしまいます。

小さくする

じゃどういう風に小さくしていくかというと、条件のうち独立したもの（＝他に影響がない）と仮定して扱っていきます。

例えば、以下のようにデータが存在すること、コピー可能性設定、状態の確認をそれぞれ一つのカタマリとして考えます。

1つ目(2×2)

Aにデータが存在する
Bにデータが存在しない

2つ目(2×2)

Aのコピー可能設定がtrueである
Bのコピー可能設定がtrueである

3つ目(3×3)

Aサーバーの状態がノーマル状態である
Bサーバーの状態がノーマル状態である

こう考えることで、掛け算が足し算になります。2×2+2×2+3×3=17パターン！！
いきなり現実的な数字になりましたね。

工夫する

もう少し考えてみましょう。 2つ目と3つ目の分け方がちょっと気になります。コピー可能設定と状態の確認はサーバーに関わらない共通処理なのでここを一緒にしたほうがいいかもしれません。
プログラマの人も共通処理にしている可能性が高いです。コードを確認できてこの通りになっているとベストですね。

1つ目(2×2)

Aにデータが存在する
Bにデータが存在しない

2つ目(2×3)

Aのコピー可能設定がtrueである
Aサーバーの状態がノーマル状態である

3つ目(2×3)

Bのコピー可能設定がtrueである
Bサーバーの状態がノーマル状態である

こうすると2×2+2×3+2×3=16パターンです。

まとめ

最初に説明したとおり、"他に影響がないとしたモデリング"をすることで、テストケース数を減らしています。重要なのはどのパラメータの結びつきが強いかを考えることです。強いと思ったところは同じカタマリにして、弱いと思ったところは別のカタマリにしましょう。
もちろん落としたテストケースでバグが出ることはあるかもしれません。
そうならないようにモデリングの確からしさを担当者に確認したり、コードを見たり、不安な場合は高めに網羅するようにしましょう。影響ないはず！というところのテストには組合せテスト（オールペア法など）で網羅していくことで安心することができます。

※2020/12/15 秋山さんのコメントを受けて組合せテストの話を追記しました。