ご無沙汰してます、QAエンジニアのざきです。
世の中の流れは早いもので、2020年も残り僅か。寒い地域は苦手なので宮崎から出られません。
はてさて
今回は数あるテスト設計技法の中から「デシジョンテーブル」について書きます。
開発内容の規模が小さい場合、頭の中で仕様を巡らせテストケースを考える事は、そう難しくはありません。
しかしながら昨今のシステム開発では、開発の規模自体が大きく、1つの処理結果を得るためにも複数の条件や前提が存在する事がしばしばあります。
複数の条件が存在するだけでも頭が痛いのですが、その条件自体が複雑に絡み合い・入り乱れる事も多く、お手上げならぬ「思考停止」に陥ります。
QAとして、潜んでいる不具合を出来るだけ多く検出するために、正しい処理結果やユースケースを理解する事は避けて通れません。
「全数テストを行う事は不可能」というテスト原則もありますが、必要なテストケースをきちんと網羅できているのか、自分の中に不安が残る状態でテスト設計を行う事は避けたいです。
どうにか考え抜いたテストケースを並べて見た時に、「抜け・漏れがないか（網羅できているか）」「省略したテストは適切なのか（必要なものを省略していないか）」が瞬時に判断出来ない時、そんな時は深呼吸してデシジョンテーブルを作ってみましょう。
デシジョンテーブルとは
簡単に説明すると、入力データ・入力条件の組み合わせに対する処理・出力結果を表形式（テーブル構成）でまとめたものです。
日本工業規格（『JIS X 0125 決定表』）で規格が定められていますが、実際の開発現場によって利用方法や作成方法は様々です。
この規格の中では「問題の記述において起こり得るすべての条件と、それに対して実行すべき動作とを組み合わせた表」と定義されています。
デシジョンテーブルの構成
デシジョンテーブルの構成は次の通りです。
ちょっとこれだけじゃ分かりにくいのでサンプルを1つ。
上の仕様に基づいてデシジョンテーブルを作成するとこうなります。
デシジョンテーブルの解説
それでは、デシジョンテーブルの構成・要素について1つずつ解説します。
①条件の一覧（条件記述部 / condition stub）
入力条件・入力データを列挙します。
②結果の一覧（動作記述部 / action stub）
条件に合わせて実行する動作や処理結果を列挙します。
③条件の組合せ（条件指定部 / condition entry）
条件の判定結果の組合せを指定します。判定結果は大半の場合、真か偽で表現します。
表現方法として以下のものがありますが、どの組合せを使っても意味は同じです。
［Y、N（Yes or No）］［T、F（True or False）］［1、0（真 or 偽）］
組合せではなく、単独で真か偽を指定する場合は以下の表現方法を使用します。
［値、単語（この行に対応する条件が、記述された値や単語を満たすことを意味する）］
［ -（この行に対応する条件が無関係であることを意味する）］
④組合せに対応する結果（動作指定部 / action entry）
条件の組合せに対応する動作結果を指定します。真か偽で表現する場合は条件指定部と同じ表現になります。
［Y、N（Yes or No）］［T、F（True or False）］［1、0（真 or 偽）］
その他の表現方法としては以下のものがあります。
［X（eXecute）：この列に指定された全条件の真偽値に合致する場合、この行に対応する動作や処理結果となる］
［空白、-：この列に指定された全条件の真偽値に合致する場合、この行に対応する動作や処理結果の対象外となる］
［値、単語：この列に指定された全条件の真偽値に合致する場合、この行に対応する動作や処理結果が記述された値や単語を満たす］
⑤規則
入力条件、入力データの組合せと、それに対応する動作や処理結果を組合せたものです。
デシジョンテーブルテストを行う際は、この各列（規則）をテストケースとして扱います。
サンプルの内容は複雑な条件組合せはありませんが、頭の中で考えるよりは理解しやすいのではないでしょうか。
デシジョンテーブルを利用すると、テストケースの内容を明確に示せるメリットも感じられると思います。
（箇条書きのテストケースは数が多いと読むのに疲れますよね ^^;）
デメリット
良いことばかりじゃないもので、デシジョンテーブルにもデメリットがあります。
これまでの経験・実践から感じているものは次の内容です。
条件を1つ増やすだけで組合せ数が跳ね上がる（収拾がつかない）
条件自体に抜け・漏れがあると全く意味が無い（ゆるゆるなテスト設計）
実行順序を考慮できない（個人差が出ます、本当に）
テストケースとして利用する際には、テストフェーズや対象システム・機能項目と照らし合わせながら判断しましょう。
やたらめったらデシジョンテーブルにしてしまうと、逆に、とっても複雑なテストを作り出してしまいますのでご注意ください。
まとめ
今回は「デシジョンテーブル」についてお届けしました。ネーミングからして難しそうな技法を使えば、最良・最善のテストが出来る、なんて事はありません。あくまでも目的（より良いテスト）の為の手段なので、使い方（あなた）次第です。
小難しい用語や、自分にはしっくりこないルールなど、テスト設計技法も本当に様々あります。 個人的に、知らないよりは知った上で、必要なタイミングで必要なものを使えればそれが最高だな！と思ってます(ﾟ∀ﾟ)
最後まで読んでいただいた皆様、お付き合いありがとうございました！
