私なりのデシジョンテーブルの書き方
はじめに
本記事は私がデシジョンテーブルを書く時に大切にしていることと、オレオレのやり方について解説します。
私のデシジョンテーブルの書き方が一般的というわけではありません。
本当の正しいやり方を知りたい人はJISを参照するか、🥦さんなどの有識者の方から聞くようにしてください。
ソフトウェアテストの小ネタAdventCalendar 2024の記事です。
デシジョンテーブルってなんなの？
ソフトウェア設計技法としてのデシジョンテーブル
デシジョンテーブルとは「ソフトウェア設計技法」です。
「デシジョン・テーブルテーブル化による思考整理学」によると以下のように記載されています。
フローチャートはオペレーティング・マネージャーとコンピュータ・スペシャリストとの間に存在するコミュニケーション・ギャップを埋めるための図形表示であり(略)フローチャートやブロック・ダイアグラムの代りに、あるいはそれらと共に用いられる
デシジョン・テーブル テーブル化による思考整理学 p23
上記の書籍によると、デシジョンテーブルは条件分岐を表現する技法のひとつです。
また、設計技法におけるデシジョンテーブルは最初から省略した形で書かれることを許容します。
テストとしてのデシジョンテーブル
デシジョンテーブルは元々ソフトウェア設計技法なのですが、テストの技法として理解されていることも散見されます。
なぜなのかは不明なのです。設計技法としてあまり使われないからでしょうか。
それはおいといて、テストとしてのデシジョンテーブルについて語ります。
まず、表現手法としてのデシジョンテーブルとは別に、「デシジョンテーブルテスト」というものが存在します。
デシジョンテーブルテストとは、
デシジョンテーブルで表現したルールをテストケースでカバレッジすること
です。
実務でのデシジョンテーブル
しかし、実務で最初からデシジョンテーブルが用意されていて、それをテストで使った経験は私はありません。
ほとんどのテスターはデシジョンテーブルを作るところから始まりまると思います。
本記事では私が実際にテスト用のデシジョンテーブルを作るにあたって、大切にしていることを書きます。
デシジョンテーブルの方針
テストとしてのデシジョンテーブルは、私は「省略しない」というスタンスを取ります。
これはマジで省略しないのではありません。（どっちや）
最終的に省略したデシジョンテーブルを作成して、デシジョンテーブルテストにすることは同じです。
ただ、私の場合は中間成果物として省略しないデシジョンテーブルは残し、なぜ省略するのかを記載するようにします。
テストにおいて、デシジョンテーブルで表現するものは「テスト条件のスコープ内で識別できる動作に対して識別できる条件の組み合わせ」だと考えます。
なので、デシジョンテーブルで表現される2のべき乗はすべて表現します。
こだわり 1.デシジョンテーブルの作成手順
JISなどの規約ではデシジョンテーブルの書き方は定義されています。
しかし、私が作成するときは順番の入れ替えをしています。
私は以下の順番です。
- 動作記述部を記載する
- 条件指定部を記載する
- 全パターン書く
- 省略する
- 〜テストケースへ〜
動作記述部を先に記載するのは、デシジョンテーブルのスコープを定めるためです。
JISのやり方は条件のすべてを記載してからパターンを出して動作指定部を書きます。
私はこのやり方はせず、テストのスコープを意識するために動作記述部から記載します。
「どんな動作を見たいのか」を先に決めることで、条件が発散せずに記載することが可能だからです。
デシジョンテーブルテストは条件をたくさん書くよりも、条件の組み合わせが大切だという理解をしています。
条件の発散であればもっと前段階で行うべきだと考え、テスト設計フェーズでは最小限の必要な組み合わせを導出します。
すべてのテストをデシジョンテーブルで表現する必要は私はないと考えています。
こだわり 2.拡張指定で書かない
デシジョンテーブルでは拡張指定を使わないようにしています。
これは私の「テスト技法はカバレッジが大切」という思想に立脚しています。
機械的に組み合わせを導出して、組み合わせパターンを出し切りやすいように、拡張指定では書かないようにしています。
こだわり3.全パターンを書く
デシジョンテーブルでは機会的に全パターンを導出します。
該当するテスト条件のスコープの最大のパターンを先に洗い出します。
最大数を出して安心したところで、省略します。
テストケース数は削りますが、必ずここで「省略した理由を書く」ことを大事にしています。
ですので、全パターンの表には「省略した理由が書かれているテスト設計成果物」として残ります。
「省略した理由を書く」のは、デシジョンテーブルの説明性を高めるためです。
とくに「関係ない」として省くことがある場合は、「実は関係あったよ」などがまれにあります。
それについて、関係者と合意を得るために積極的に残すようにしています。
こだわり4.省略したテーブルを書く
最終的にデシジョンテーブルはテストケースとして記述されるので、省略したテーブルも書きます。
省略したテーブルは、組み合わせとテストケース数の観点でテストケースのレビューに使用します。
なので、ごまずんのデシジョンテーブルは最低でも2つ作成されます。
おわりに
デシジョンテーブルの作成方法が流行っているみたいなので、私のやり方を記載しました。
これは正しい教科書通りのやり方ではないので、自分自身できちんと調べて考えるか、偉い人に習うようにしてください。
Discussion