磯野〜デシジョンテーブル書こうぜ
明けましておめでとうございます🎍iCARE QAEチームのじゃっきーです。
ついに始まりましたね。
宇多田ヒカル6年ぶりツアーの申し込みが…
我が家は夫婦でヒカル推しなので大変です。
そんなこんなで当たるといいなと祈っています🙏
さて本題です。
まずデシジョンテーブルとは
弊社でも、プロジェクトを進行していく中で複数の条件分岐が発生し、その複雑さからテキストの説明だけではその場にいる全員の認識を一致させられないことがたまにあります。
適当な具体例をつくってご説明します。
どうでしょう?パッと答えられる方はそのまま弊社QAチームの面接を受けにきてくださいいつでも待ってます。
ちょっと何言ってるかわからないっすね…という方は私と握手🤝
そんなとき役に立つのがデシジョンテーブルです。早速作って行きましょう。
デシジョンテーブルを作ってみる
1. 条件と期待値を書き出す
まず条件と期待値を書き出して行きます。
考え得る条件と期待値を脳みそから絞り出します。
ここで抜け漏れがあると後でいろいろなことが終了してしまいます。
もしも仕様書やmtgの議事録などがあればここで読み込んでできるだけ丁寧に書き出すようにします。
2. 条件について、組み合わせで該当する/しないを書いていく
私、今までここをわりと行き当たりばったり書いてしまったりしていたのですが、QA技術顧問のブロッコリーさんから「ロジカルに書く方法」を教わったのでそちらで書いていきます。
まず、最下部の条件に該当する(⚪︎)、もしくは該当しない(×)を記入します。
次に、作った最下部の条件⚪︎×をコピペで右隣に増やし、その上部の条件分⚪︎×を記入していきます。あとはそれを最上部までコピペで繰り返していくだけ!
今回は2の7乗なので128パターン、無事に書き出せました。
3. 期待値について、組み合わせで該当する/しないを書いていく
条件を見ながら、表示できる画面の期待値にxをつけていきます。
4. 実装を確認し、エンジニアさんと相談しながら適切なテストケースに絞っていく
3で全ての表示パターンは書き出せましたが、全てをテストするぞー!なんてことをすると無駄が出ますし、スケジュールによってはチームの皆様をどえらい目に合わせてしまいます。
なので、重複していそうな組み合わせや実装上確認しなくても良さそうなテストケースをギュッと絞っていきます。
結果128パターン→20パターンのテストまでテストを絞ることができました。
実装内容が変わった場合や懸念点がある場合は、ここから更にテストを増やしたりもします。もちろん、めちゃくちゃ不安だから全パターンテストしたい!ということも稀にあるかもしれません。その場合は全部テストします(滅多にないと思いますが)。必要に応じてですね。
おわる
いかがでしたでしょうか。
デシジョンテーブルをつくってぜひぜひお仕事をわかりやすくしていきましょう。
「おい待て、お前このデシジョンテーブル間違ってるぞ…?」と思ったそこのあなたはぜひぜひ弊社に遊びにきておしゃべりしましょう〜!待ってます🏢