デシジョンテーブルテストについてちゃんと勉強してみた
書いている人の経歴
こんにちは。SHIFTのDevOps推進部のアジャイル開発2Gに所属している野口 真人です。2019年9月にSJHIFTに入社しまして、最初の1年ほどはAPIテストの自動化をしていました。
その後、半年ほどは手動テストの設計～実装～実行～完了作業をおこない、ここ1年ほどはテスト管理作業をメインでおこなっています。 SHIFTに入社するまでは15年ほどシステム開発をしていました。ただし、ソフトウェアテストについて学んだことはなく、経験と勘で単体テスト、結合テスト、システムテストなどを実施していました。
きっかけ
JSTQBのテストアナリストを受験するにあたり、テスト技法を学んだため、せっかくなら学んだことをアウトプットしようと思ってブログを書いてみます。
読んで欲しい人
私と同じようなキャリアの人に読んでいただきたいです。
ソフトウェア開発の経験はあるが、ソフトウェアテストの勉強をきちんとやったことがなく、これから勉強したいと思っている方に読んでいただけると参考になると思います。
デシジョンテーブルテストとは何か
デシジョンテーブルは「条件のセット」と「関連するアクション」を表形式にし、条件値に対するアクションのルールを表したものです。このデシジョンテーブルを用いることで、対象ソフトウェアのルールをカバーするテスト設計が可能になります。
文章だけだとわかりづらいのて、スポーツジムのシステムを例にして考えます。このスポーツジムは会員種別や会員の属性で、月会費と利用可能日時が決定されます。この組み合わせをテストすることを想定して、デシジョンテーブルを作成していきます。
＜会員ごとの月会費と利用可能日時、および会員属性による割引の仕様＞
・会員にはウィークデー会員、ウィークエンド会員、アーリーバード会員、ナイト会員の会員種別が存在する。
・ウィークデー会員は月会費が7,000円、平日の9:00～21:00まで使用可とする。
・ウィークエンド会員は月会費が10,000円、土日祝日の全営業時間が使用可とする。
・アーリーバード会員は月会費が3,000円、全営業日の6:00～9:00が使用可とする。
・ナイト会員は月会費は5,000円、平日の21:00～24:00が使用可とする。
※同一人物が複数の会員種別に登録することはできない。
・年齢が70歳以上の場合、会員種別にかかわらず月会費は1,000円引きとなる。
・学生の場合、会員種別にかかわらず月会費は1,000円引きとなる。
・70歳以上で学生の場合は、月会費1,000円引きとなる。
この仕様に基づいて、「条件のセット」「関連するアクション」を表形式にしてデシジョンテーブルを作成します。
今回の例であれば、会員種別、会員の属性（年齢、学生）が「条件のセット」であり、月会費、利用可能日時が「関連するアクション」となります。
上記の仕様を元に作成したデシジョンテーブルがこちらになります。
デシジョンテーブルができたので、これを元にテストケースを実装していくことができます。
今回の例のように文章で条件が羅列されている場合、そこから漏れなく組み合わせのテストをするのは難しいため、デシジョンテーブルで表形式にすることでテストの見通しが立ちテストケース漏れ、無駄なテストケースを削減することができます。
上で作ったデシジョンテーブルを元にテストケースを作ると以下のようになります。
1 ウィークデー会員で70歳未満、学生でない場合、月会費は7,000円、利用可能日時は平日の9:00～21:00であること
2 ウィークデー会員で70歳未満、学生の場合、月会費は6,000円、利用可能日時は平日の9:00～21:00であること
3 ウィークデー会員で70歳以上、学生でない場合、月会費は6,000円、利用可能日時は平日の9:00～21:00であること
4 ウィークデー会員で70歳以上、学生の場合、月会費は6,000円、利用可能日時は平日の9:00～21:00であること
（略）
16 ナイト会員で70歳以上、学生の場合、月会費は4,000円、利用可能日時は平日の21:00～24:00であること
このように、デシジョンテーブルを作ることで、テストケースの洗い出しがスムーズに行え、抜け漏れがないことがわかりやすくなります。
仮にデシジョンテーブル形式でビジネスルールやシステム仕様が書かれていれば、それをそのままテストケース作成時に利用することができます。ただし個人的な経験では、デシジョンテーブル形式でビジネスルールが記述されていることはほとんどなかったです。 その場合、テスト担当者がデシジョンテーブルを作ることになるのですが、ビジネスルールを一覧で見えるようになるのは大きなメリットです。というのも、作成した表を使って要求元や開発者と会話することで、要求の漏れや開発の漏れをテスト実施前に発見することができるようになるからです。
今回のサンプルで言えば、「70歳以上で学生の場合は、月会費1,000円引きとなる。」という補足が料金仕様に書いてありましたが、こういった補足がないことはあると思います。その際にデシジョンテーブルを作ることで70歳以上で学生だったらどうなるんだろうと疑問を持ち、仕様の曖昧な部分を質問することで、要求側の漏れや開発の漏れに気づくことができます。
まとめ
JSTQBのシラバスにも載っているテスト技法「デシジョンテーブルテスト」について紹介しました。
複数の条件の組み合わせを抜け漏れなく洗い出すには良いテスト技法です。
仕様書の文書が複雑な場合、デシジョンテーブルにすることで思考の整理にもつながりますし、他の人と認識合わせをするツールにも成りえます。
参考にしたシラバスはこちらです。
http://www.jstqb.jp/dl/jstqb.jpdlJSTQB-SyllabusALTA_V311.J03.pdf
執筆者プロフィール：野口 真人（Noguchi Masato）
東京都出身。趣味は登山とランニングだが、コロナ禍でどちらも控え気味。
テストをもっと知りたい欲が出てきて、JSTQBを足掛かりにテストの奥深さを勉強中。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/