見出し画像

磯野〜デシジョンテーブル書こうぜ

明けましておめでとうございます🎍iCARE QAEチームのじゃっきーです。

ついに始まりましたね。
宇多田ヒカル6年ぶりツアーの申し込みが…
我が家は夫婦でヒカル推しなので大変です。

私:プレミアムチケット1枚27500円か…どうする…?
夫:6年ぶりだぞ??1年ずつ行けてたらって考えると結果激安やんマッツミケルセンのチケットはいくらだったか考えてみなさい
私:マッツミケルセンは健康にいいので実質無料です
夫:じゃあ宇多田ヒカルだって無料じゃん…
私:確かに….?(申込ポチ)

そんなこんなで当たるといいなと祈っています🙏

これは6年前に行ったツアー 写っているのは知らない人

さて本題です。

まずデシジョンテーブルとは

デシジョンテーブル(決定表)とは、対象が取り得る条件(入力)と、その結果の動作(出力)を洗い出した上で整理し、マトリクス上に一覧化した表のことです。
条件と動作の関係を網羅的に視覚化することで、複雑な条件と動作の組み合わせが整理され、そのロジックの理解を容易にするとともに、抜け漏れを防ぐことができるというメリットがあります。

デシジョンテーブルは日本産業規格のJIS X 0125:1986において「決定表」として規格化されており、日本語で「決定表」と呼ばれることもあります。またソフトウェアテストにおいては、ブラックボックステスト技法のひとつである「デシジョンテーブルテスト」で活用されます。

デシジョンテーブル(決定表)とは|その概要から作り方までわかりやすくご紹介

弊社でも、プロジェクトを進行していく中で複数の条件分岐が発生し、その複雑さからテキストの説明だけではその場にいる全員の認識を一致させられないことがたまにあります。
適当な具体例をつくってご説明します。

駄菓子屋のお菓子を管理する画面があり、「購入候補」「購入予約済」「購入済」という工程で画面が分かれています。
「購入候補」には「飴」「チョコ」「ポテチ」「その他」というカテゴリで画面を切り替えられる機能がありますが、「購入予約済」「購入済」ではすべてのカテゴリが1つのページに一緒に表示されます。

各工程とカテゴリは設定画面で表示のON/OFFが設定でき、すべての表示をOFFにすると画面に404が表示されます。
また、工程かカテゴリどちらかが1つもONになってない場合にも404が表示されます。

この場合に考えられる画面表示パターン数と適切なテストケース数はどれくらいになりますか?

どうでしょう?パッと答えられる方はそのまま弊社QAチームの面接を受けにきてくださいいつでも待ってます。

ちょっと何言ってるかわからないっすね…という方は私と握手🤝
そんなとき役に立つのがデシジョンテーブルです。早速作って行きましょう。

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

1. 条件と期待値を書き出す

まず条件と期待値を書き出して行きます。

もうここがいちばんの山場

考え得る条件と期待値を脳みそから絞り出します。
ここで抜け漏れがあると後でいろいろなことが終了してしまいます。
もしも仕様書やmtgの議事録などがあればここで読み込んでできるだけ丁寧に書き出すようにします。

2. 条件について、組み合わせで該当する/しないを書いていく

私、今までここをわりと行き当たりばったり書いてしまったりしていたのですが、QA技術顧問のブロッコリーさんから「ロジカルに書く方法」を教わったのでそちらで書いていきます。

YとNで書く時と⚪︎と×で書く時があります。気分です。

まず、最下部の条件に該当する(⚪︎)、もしくは該当しない(×)を記入します。

次に、作った最下部の条件⚪︎×をコピペで右隣に増やし、その上部の条件分⚪︎×を記入していきます。あとはそれを最上部までコピペで繰り返していくだけ!

コピペだけで
ガンガン書けます。

今回は2の7乗なので128パターン、無事に書き出せました。

3. 期待値について、組み合わせで該当する/しないを書いていく

条件を見ながら、表示できる画面の期待値にxをつけていきます。

コツコツ…
ある程度書いたら
コピペして
コピペデータを加工してちょっぴり楽をします。その繰り返し。
ハァッ ハァッ なんとかできました

4. 実装を確認し、エンジニアさんと相談しながら適切なテストケースに絞っていく

3で全ての表示パターンは書き出せましたが、全てをテストするぞー!なんてことをすると無駄が出ますし、スケジュールによってはチームの皆様をどえらい目に合わせてしまいます。

なので、重複していそうな組み合わせや実装上確認しなくても良さそうなテストケースをギュッと絞っていきます。

品質もチームの定時帰宅も守れるテストを目指す(定時帰宅できるとは言っていない)

結果128パターン→20パターンのテストまでテストを絞ることができました。
実装内容が変わった場合や懸念点がある場合は、ここから更にテストを増やしたりもします。もちろん、めちゃくちゃ不安だから全パターンテストしたい!ということも稀にあるかもしれません。その場合は全部テストします(滅多にないと思いますが)。必要に応じてですね。

おわる

いかがでしたでしょうか。
デシジョンテーブルをつくってぜひぜひお仕事をわかりやすくしていきましょう。

「おい待て、お前このデシジョンテーブル間違ってるぞ…?」と思ったそこのあなたはぜひぜひ弊社に遊びにきておしゃべりしましょう〜!待ってます🏢


この記事が気に入ったらサポートをしてみませんか?