いまさらデシジョンテーブルというものを考えてみた

こんにちは、ゆーすけです。
V&V」「シフトレフト」に続く、いまさらシリーズの第3回です。
今回は、ブラックボックステスト技法の一つである「デシジョンテーブルテスト」について考えてみたいと思います。

デシジョンテーブルとは

一旦、JSTQB FLシラバスでどのように定義されているか確認してみましょう。
(以下JSTQB FLシラバス抜粋)

「デシジョンテーブルは、システムが実装すべき複雑なビジネスの規則を表現するのに有効である。デシジョンテーブルを作成する際には、テスト担当者は条件(主に入力)と結果的に起きるシステムのアクション(主に出力)を識別する。条件とアクションは表の行となり、条件を上部、アクションを下部に記述する。各列は判定の規則に対応している。規則は条件の一意な組み合わせとその結果として実行するアクションを表す。」

(抜粋終了)

上記を要約すると、

・システムの実装仕様が複雑な部分に使うと有効なテーブル(表)である。
・表の構成は、条件(入力)とアクション(アクション)を縦軸として、
 条件を上部、アクションを下部とする。
・条件とアクションの紐づけを行う
※条件〇〇であれば、アクション△△になる、といったように

というかたちになりますが、要約しても文章で表すのは分かりづらいので実際に
簡単な表を作成してみましょう。

デシジョンテーブル作ってみた

デシジョンテーブルの作成例として施設入館料がよく出てきますので、ここでも施設入館料を想定して考えてみます。

 想定:
  映画館のチケット割引サービス
 
 仕様:
  通常金額1900円
 
 割引システム:
  ファーストデイ:毎月1日はだれでも1200円
  レディースデイ:毎週水曜日は女性なら1200円

まず上記仕様から条件とアクションを抜き出してみましょう。

 条件:
  日付:1日か、それ以外か
  曜日:水曜日か、それ以外か
  性別:女性か、それ以外か

 アクション:
  金額:1900円か1200円か

これをテーブルにすると以下のようなかたちになります。

これらの要素に対して、判定を期待していくかたちとなります。
JSTQB FLシラバスでは

「条件:

・Y:条件が真であることを意味する(T または 1 とも記述する)
・N:条件が偽であることを意味する(F または 0 とも記述する)
・ー:条件の値は判定に影響しないことを意味する(N/A とも記述する)。

アクション:

・X:アクションが発生することを意味する(Y、T、または 1 とも記述する)」

とありますので、これに準じて判定を追加していくとテーブルは下記の通りになります。

デシジョンテーブル省略してみた

上記テーブルだとテストケース数が多いので、省略出来る部分を確認していきましょう。
元仕様では

 ファーストデイ:毎月1日はだれでも1200円

と記載されているので日付が1日であれば曜日も性別も任意というわけです。
ここの部分を省略化すると下記のようなテーブルになります。

※条件1日が満たされていればアクション1200円となる

これで想定テストは8ケースから5ケースへと省略できましたが、
上記デシジョンテーブルではまだ省略を検討できる部分があります。

仕様では

  レディースデイ:毎週水曜日は女性なら1200円

とありますが、これは「水曜日以外は1900円」という意味にもなります。
それを元に考えるとテーブルはさらに下記のように省略することができます。

デシジョンテーブル省略してもいいの??

テストケース数も最小値となり、一見これでよいようにも見えますが、
JSTQB FLシラバスにはテストケースの省略に関して

「条件の組み合わせが起こりえないといった、結果に影響しない列を削除することにより、 テストケース数を大幅に減らすことができる。デシジョンテーブルを簡単化する方法の詳細について は、『ISTQB テスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト』を参照されたい。」

と記載されています、
素直にテストアナリストシラバスを見てみると、

「簡単化したデシジョンテーブルは、完全なデシジョンテーブルに比べてルールの数がはる かに少ない場合があり、結果的にテストケースの数が少なくなり工数が軽減できる。もし、あるルールに「関係なし」という項目があり、そのルールをカバーするテストケースが 1 つしかない場合、そのルールでは、条件の中でテストできる値のうち 1 つしかテストされないため、他の値に含まれる欠陥が検出できないかもしれない。」

つまり、工数は減るけど検出漏れになる危険性を考慮する必要がある、と記載されているわけです。

最後に作成したテーブルから考えられる判定フロー図は下記のようになります。

実際このようなフローで実装されていれば作成したデシジョンテーブルでも問題ありませんが、実際の「分岐の順番はどうなっているか」「変数、フラグ処理はどうなっているか」は割引仕様では不明のため、「条件(入力)を省略できるか」という点は内部ロジックを気に掛ける必要が出てくると言えます。

もしかしたら、

・初期値として「1900」という数字を所持
・1日なら-700円
・水曜日かつ女性なら-700円

という実装になっていて、その結果

・1日かつ水曜日かつ女性であれば500円(1900-700-700)になってしまう。
・曜日と性別は任意にしたため、上記不具合の検出が漏れた

ということも極論考えられてしまう、というわけです。

最後に

デシジョンテーブルは基本的なブラックボックステストの技法と言えますが、
効率かつ効果的な省略を行うためには内部構造理解が必要になってきます。
書籍、webサイト記事でも、デシジョンテーブルの扱い方として
省略できる、ということを記載していないものや、省略するとリスクがある、程度にとどまっているものも多いので、「何故省略するとリスク(検出漏れ)があるのか」ということをキチンと把握してうえで、技法の活用を行っていきましょう。

#デシジョンテーブル #ブラックボックステスト

SHARE

  • facebook
  • twitter

SQRIPTER

AGEST Engineers

AGEST

記事一覧

AGESTのエンジニアが情報発信してます!
AGESTのサービスやソリューションのお問い合わせページはこちらです。

株式会社AGEST

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST