【ソフトウェアテスト】デシジョンテーブルテスト

公開日: 2025/1/29
さまざまな入力値が想定されており、それぞれの入力値を統合した結果として複数の状態を返すようなシステム仕様に対しては、デシジョンテーブルテスト技法を用いることで、複雑な条件を整理することができます。

サービス利用時に新規アカウントを作成するような場面で、ユーザー情報を入力して登録する機能を想定した場合、[名前(ローマ字)][よみがな][任意のパスワード][パスワード確認入力][年齢][住所]などを入力し、それらの入力値が全て正常であれば登録処理を進めて、入力値のうち1つでも正常ではない値が入力されている場合は、エラーメッセージを表示して再度入力を促すようなシステムがあります。


対象のステータスによって期間限定のサービス適用有無を判定するようなシステムでも、サービス対象となるかどうかを複数条件から判定するような仕様が想定されます。

5年以上サービスを利用していて、アカウントの利用者ランクがゴールド以上の場合、商品購入時の金額から5%をサービス固有ポイントとして還元するというイベントを、n年n月n日~n年n月n日まで開催するといった追加開発システムのテストをする際に、デシジョンテーブルによってテスト対象を適切に抽出できます。

1. システム要件の一例


あるWebサービスの初回利用者を対象に、特定SNSアカウントとの連携登録で新規アカウントを作成すると、サービス内で使用できるポイントを1回付与するという期間限定イベント施策の要件を定義します。

■初回限定ボーナスポイント付与の仕様

 ・イベント開催は11月1日の12:00:00から11月8日の12:00:00までが対象

 ・イベント開催期間内に新規アカウント作成したユーザーが対象

 ・このWebサービス内で使用できるSNSサービスアカウント[A][B][C][D]のうち、連携でポイント対象となるのはSNSサービス[B][C]

 ・対象のSNSアカウント連携でアカウント作成してトップページに遷移した時点で500ポイントが付与される

 ・イベント開催時刻以前にアカウント作成していたユーザーは対象外

2. デシジョンテーブルの作成

仕様を元に、デシジョンテーブルの条件と結果の動作を考えます。

その条件によって処理がTrue・Falseどちらかになるというものを条件として設けます。

・条件

 ① 11月1日 12:00:00 から11月8日 12:00:00の間にログイン

 ② SNSサービス[B][C]アカウント連携で新規アカウント作成をしてログイン

各条件を満たしている場合に想定される動作を書き出します。

・動作

 イベントポイント付与


以上の内容を元にデシジョンテーブルを作成します。

・新規登録者ボーナスポイントイベントのデシジョンテーブル



各条件に対してのステータス記載について

 ・条件が成立する場合は[Y:Yes]

 ・条件が成立しない場合は[N:No]

で記載しています。


また、条件組み合わせの結果

 ・対象の処理が実行される場合は[X]

 ・対象の処理が実行されない場合は空欄

で記載しています。


特に厳密な記載方法が定められているものではないので

 ・条件が成立する場合は[T:True]や[○]、

 ・条件が不成立の場合は[F:False]や[×]

と記載することもあります。


今回は判定条件が3つで、結果となる動作が1つだったので、デシジョンテーブルも比較的単純な形になりました。

これをテストケースとしてチェックリストに起こすとしても、確認するのは

 ・イベントポイント付与成立2パターン

 ・イベントポイント付与不成立2パターン

の計4パターンのみで済みます。

3. 条件追加



開発を進めていく中で、要件や仕様が変更追加されることはよくあります。

また、以前に作成した機能に部分的な追加を施して、別の機能として追加リリースするということもあります。

条件に追加があったことを想定して、デシジョンテーブルの条件も追加していきます。

■追加条件

・対象とするSNSサービスは[B][C]のほかに[D]も追加して[B][C][D]とする

・アカウント登録後に、プロフィール設定を完了させてトップページに遷移した時点でポイントを付与する


上記の追加条件をデシジョンテーブルの条件として追加します。

・条件

 ① 11月1日 12:00:00 から11月8日 12:00:00の間にログイン

 ② SNSサービス[B][C][D]アカウント連携で新規アカウント作成をしてログイン

 ③ 新規アカウントでログイン後にプロフィール設定を完了させる


以上の追加内容を、先ほどのデシジョンテーブルに追加していきます。


・条件追加後の新規登録者ボーナスポイントイベントのデシジョンテーブル



今回は判定条件が5つで、結果となる動作が1つになり、確認対象パターンがイベントポイント付与成立3パターンと、イベントポイント付与不成立9パターンで計12パターンとなり、追加前と比べて3倍になりました。

このように条件が増えるごとに確認対象も比例して増加していき、全ての確認対象を確認しようとするとテスト工数がかさんでしまうので、デシジョンテーブルを「簡単化」する必要があります。

4. 簡易化

同じ結果を返す項目の中で、一定条件でまとめられるものは一つの項目として統合します。


項目7と項目8は、連携登録するSNSサービスは同じく[B]であり、プロフィール設定がYかNかで別れていますが、最初の条件である11月1日 12:00:00 から11月8日 12:00:00がNのため、その時点で対象外として処理されます。

プロフィール設定がYかNかの判定にたどり着く前に、前の条件で対象外になることが分かっているため、プロフィール設定の判定はどちらでも良くなります。

このようにどちらでも結果が変わらない項目を[-]に変更して、項目7と項目8を統合することができます。


項目9と項目10、項目11と項目12も、連携登録するSNSサービスが[C]か[D]かの違いのみで、そのほかは上記の項目7項目8と同じ内容なので、これも統合できます。

・簡単化後の新規登録者ボーナスポイントイベントのデシジョンテーブル



5. テスト実施想定

作成したデシジョンテーブルの順序のままでテストを実施しようとすると、期間内に[B]のSNSでアカウント連携した後にプロフィール設定をしてポイント付与挙動を確認したあと、別の[B]SNSアカウントを新たに作成した上でプロフィール設定をせずにポイントが付与されないことを確認するような順序になってしまい、目標とする期待結果を確認するテスト作業に無駄が生じてしまうので、実際のテスト順としては、期間内に[B]のSNSでアカウント連携したところでトップページなどに遷移してポイントが付与されないことを確認した後、そのアカウントでプロフィール設定をしてトップページへ遷移したときにポイントが付与されることを確認するといった順序が想定されます。

また、前項で簡単化した項目7以降は、対象期間外に新規ログインするので条件外としてプロフィール設定はどちらでも良いとしていますが、テストを実施する際は、適用期間外にアカウント連携で新規作成し、プロフィールを設定した場合にポイントが付与されない動作を確認することで、日時による判定が正常であることと、適用期間外にプロフィール設定を実行し誤ってポイントが付与されないことを確認します。

デシジョンテーブルはあくまで複数条件による判定を整理し簡潔にするものなので、ここからテストケースやチェックリストを作成する場合は、そこからさらに実際のユーザーを想定したケース作成が必要になります。