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

今回はテストの小ネタということで、爆発しがちなデシジョンテーブルを抑え込むちょっとしたコツです。 ソフトウェアテストの小ネタの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 秋山さんのコメントを受けて組合せテストの話を追記しました。