はじめまして。
スマートフォンチームの平良です。
先日、第１回LT(ライトニングトーク)を行いました。
(といっても行なったのは8月頃です...遅筆ですみません！)
テーマは、平良式デシジョンテーブルについてです。
今回は、テスト設計に活用することを目的としたデシジョンテーブルをなんとな〜く思ったより楽に書けそうって気持ちになることを目的に、かる〜く話させていただきました。
まず、デシジョンテーブルとはなんぞやというと...こんな感じのものです。
ただのパターン洗い出し表ですね。
メリットは...
・レビューしやすい
・ケース追加、修正が楽
・緊急対応時の簡易ケースとして活用可能
・テストケースに日本語を書かなくてもいい
デメリットは...
・初めは作成に時間がかかるので、慣れが必要
・実行者が仕様をある程度把握していないとQAが多くなる
・行列数が多くなるとみづらい(対策 → 小分けにする)
デメリットに関しては、数をこなせばできるようになってきますので、
慣れればメリットだらけです！
作成する上で自分の頭の中での作成手順です。
「要件再整理(1) → ざっくりシナリオ(2) → パターンの洗い出し(4) → デシジョンテーブルへ起こす(2) → キレイにする(1)」
※()はそれぞれのパワー比重
一番比重が高い「パターンの洗い出し」ですが、
条件分岐を意識するとじゃぶじゃぶ出てきます。
例えば、
switch a {
case 0:
0だね〜
case 1:
1だよ〜
default:
break
}
とあった場合、
a = 0 a = 1 a ≠ 0&1
のパターンが考えられます。
といった具合に、
条件分岐を意識して考えていくとパターンがじゃぶじゃぶ出ます。
また、他にも個人的に作成する際に気をつけていることとして、
・左上から右下へキレイに「●」が並ぶように工夫する
(あっちこっちに点在するよりは、規則性がある方が見やすい)
・同じ文言は極力書かない
(同じ文言があるってことは、1つにまとめられるということ)
・文言は短く、端的に書く
(「**である」とか「**となっていること」ではなく、「**が表示」で意味は通じる)
・無理して1つの表に収めようとしない
(行も列もダラーっと長くなっていたら、見るのも嫌になる)
上記の説明後、LTでは実際にライブ作成して見せました。
・・・
いかがでしたでしょうか？
完成形から見せるとウェッってなる人がいますが、
自分でイチから作って見ると案外難しいものではありません。
複雑な条件の処理でパターンがじゃぶじゃぶ出て、表がキレイに作成できた時は、
思わずうっとり...します。