テストの初心者がディシジョンテーブルを実際に作成してみた！
このシリーズは、私自身の「初心者研修記録」をもとに、研修で学んだテスト技法を実務でどのように活用したのかを記録したものです。
今回はその中から、実務で初めてテスト技法を意識的に活用した取り組みとして、「状態遷移図」を用いた検証の記録を整理し、記事としてまとめました。
私自身、ソフトウェアテスト受託業務の企業に就職してまだ3カ月ほどであり、ソフトウェアテストに関しては社内研修で学んだ知識しか持っていない状態でした。
実務経験がほぼない中で、研修で学んだテスト技法をどのように業務に落とし込んだのか、その過程と考えたことを初心者の視点で残しておきたいと考え、今回の記事を作成しています。
※本記事は株式会社モンテカンポの新人スタッフが記録したレポートを元に、記事として編集しなおしたものとなります。
| 私について簡単に自己紹介をします。 前職では、サーバ（ハードウェア）開発に関連する業務に従事していました。 そのため、ソフトウェア開発やソフトウェアテストに関しては、実務として深く関わる機会はほとんどありませんでした。 ソフトウェア分野の基礎知識としては、基本情報技術者試験の資格を取得していますが、あくまで座学ベースの理解に留まっており、実際のテスト業務は未経験の状態で現在の会社に入社しました。 そのようなバックグラウンドを持つ私が、研修で学んだテスト技法をどのように理解し、どのように実務で使おうとしたのかが、今回の前提となっています。 |
今回活用するテスト技法
今回は、テスト技法の一つであるディシジョンテーブルの作成に挑戦します。
ディシジョンテーブルとは、複数の条件とその組み合わせに応じた結果（動作）を表形式で整理するテスト技法です。
条件ごとに「はい／いいえ」などのパターンを洗い出し、それぞれに対するシステムの振る舞いを明確にすることで、抜け漏れのないテスト設計が可能になります。
特に条件分岐が多く複雑な仕様の確認に有効で、網羅的かつ効率的にテストケースを作成できる点が特徴です。
弊社の別記事でも説明しています。
テスト内容
以下の検証業務を対象として実施します。
※検証対象は社外秘のため、本資料用に一部の仕様改変および名称変更を行っています。
【キャンペーン概要】
無料ドリンクチケットをギフトできるキャンペーン
条件を達成したアカウントごとにURLを付与し、そのURLからコメントを添えて、URLまたはSNSでチケットギフトを送ることができる仕組みです。
【送り手側の操作】
| 1. 条件を達成したアカウント（ギフト送り手）が付与されたURLにアクセスします。 2. コメント入力後、「URLで共有」か「SNSで共有」を選択します。 「URLで共有」の場合：専用URLが発行されます。送り手は任意の方法でそのURLを共有します。 「SNSで共有」の場合：送り手はモーダルから送付先のSNSアカウントを選択し、ギフト受け取り用リンクを送ります。 |
【受け手側の操作】
| 1. ギフト受け手は、共有されたリンクから受け取り画面にアクセスします。 2. ドリンク受け取り店舗を選択し、その店舗で使用できるチケットを受け取ります。 |
【検証要件】
| ・Webサイト内の表示および表記ゆれの確認 ・各画面の遷移確認 ・ギフト送り手側のURLごとのアクセス権限確認 ・ギフト受け手側のURL共有時、ギフト取得の有無による自他アカウントからのアクセス権限確認 ・ギフト受け手側のSNS共有時、自他アカウントからのリンクアクセス権限確認 |
テスト技法の活用検討
項目検討
今回は送り手側と受け手側で作業が独立しているため、それぞれに対して「リンクアクセス時の画面」という観点でディシジョンテーブルを検討します。
4.1.1 送り手側
【入力値】
| 初回アクセス、他アカウントによるアクセス済み、送付済み、SNS発行（またはURL発行）、キャンペーン期間中 |
【出力値】
| アンケート回答画面、キャンペーントップ画面、URL発行済み画面、SNSリンク発行済み画面、期間外エラー画面、アカウントエラー画面 |
受け手側
【入力値】
| SNSで受け取り（またはURLで受け取り）、初回アクセス、他アカウントでのアクセス、受け取り済み、使用済み、発行期限内、有効期限内 |
【出力値】
| 非対象アカウントエラー画面、チケット受け取り画面、チケット表示画面、使用済み表示画面、リンク期限切れエラー画面、有効期限切れ表示画面 |
作成で苦労した点
最初に項目を検討した際、前回の状態遷移表と同じ考え方で条件を並べてしまい、以下のように「～の時」という重複のない条件を羅列してしまいました。
【入力値】
| 送り手用URL初回アクセス時 チケットギフトのコメント入力済みURLアクセス時 チケットギフト送付済みURLアクセス時 他アカウントでアクセス済みURLにアクセス時 ・ ・ ・ |
しかし、ディシジョンテーブルの強みは複数の条件が重なる場合の振る舞いを確認することにあります。条件を単に羅列するだけでは、この技法を有効に活用できません。
また、項目数は条件がn個の場合に2^nずつ増えていくため、手作業での管理には限界があります（n=7で100件を超過します）。そのため、すべての状態を網羅するのではなく、特定の条件に絞って使用するのが現実的だと感じました。
項目の精査
項目数が多くなりすぎたため、以下のように絞り込みを行いました。
送り手側
「SNS発行かどうか」の項目を削除しました。
発行後の遷移先が少し変わるだけで影響度が小さいためです。
【入力値】
| 送り手用URL初回アクセス 他アカウントがアクセス済 チケットギフト送付済み キャンペーン期間中 |
【出力値】
| アンケート回答画面 キャンペーントップ画面 キャンペーン期間外エラー画面 アカウントエラー画面 |
受け手側
同様に「SNS発行かどうか」を削除しました。
また、一見項目が多いですが「初回アクセス」と「受け取り済み」のように両立できない条件があるため、それらを整理することで項目を圧縮しました。
【入力値】
受け手用リンク初回アクセス 他アカウントでアクセス チケットギフト受け取り済 チケットギフト使用済 チケット発行期限内 チケット有効期限内 |
【出力値】
| 非対象アカウントエラー画面 チケット受け取り画面 チケット表示画面 使用済みチケット表示画面 リンク有効期限切れエラー画面 |
ディシジョンテーブルの作成
※実際の表構成については、以下のルールに基づき作成しています。
| 送り手側：両立できない条件はグレーアウトして整理。 受け手側：項目数が多いため、両立できない組み合わせは非表示。 |
送り手側
受け手側
効率的な作成方法
項目数が多いと、出力値のチェックで見落としが発生しやすくなります。
そこで「3値以上の条件を持つディシジョンテーブル」の手法を試してみました。
例えば、受け手側の条件を以下のようにまとめます。
| 「初回アクセス」「受け取り済み」「使用済み」を統合し、「チケット使用状況」という3値の項目にする。 「発行期限内」「有効期限内」を統合し、「期限の状態」という3値の項目にする。 |
これにより、2進法的な組み合わせ（2^n）から大幅にパターン数を削減できました。
両立不可な項目を探す手間が省け、条件の見通しが非常に良くなります。
慣れればケアレスミスも防げるため、非常に有効な手段だと感じました。
まとめ
今回の検証を通して、ディシジョンテーブルは複数の条件が絡み合う対象の結果を確認するのに非常に有用だと再認識しました。
特に「他アカウントでのログインエラー」と「有効期限切れエラー」のどちらが優先されるか、といった優先順位の確認には最適です。
作成にあたっては、いかに項目を整理し、見やすく減らすかが、この技法をうまく使いこなすコツだと言えるでしょう。
QA業務効率化ならPractiTest
テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！
PractiTest(プラクティテスト)に関する
お問い合わせ
トライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
この記事を書いた人
株式会社モンテカンポ新人テストスタッフA。
前職では、サーバ（ハードウェア）開発に関連する業務に従事。
ソフトウェア開発やソフトウェアテストに関しては、初心者。
基本情報技術者試験の資格を取得。実際のテスト業務経験をいま積んでいる。
経験のなかで学んだことを記事として公開中。
記事編集：川上サトシ（マーケター、合同会社ぎあはーと代表）