【ソフトウェアテスト】クラシフィケーションツリー技法
クラシフィケーションツリー技法は主に、複数のテスト対象と各対象の値が複数関連する状況で、各対象を木構造で図示することで、テスト対象の機能や状態を階層的に分類し、その組み合わせや変数いくつ分を対象とするか等の組み合わせの強度について、整理検討するときに用いる技法です。
ドメイン分析テスト技法の際には、複数の境界値による動作変化の関連性と、その組み合わせで想定される複数パターンの網羅を表形式で表現する方法を取りましたが、クラシフィケーションツリー技法では、1つの機能に関わる複数の要素、各要素に想定される複数パターン、各パターンで想定される変数のパターンと、想定される内容を木構造の図で上から下へ記載して整理する方法を取ります。
ブラウザベースでWebサイトを作成して、ウィンドウの表示サイズをPCサイズのレイアウトとスマホサイズのレイアウトで2パターン適用するとして、PCサイズレイアウトが正常に適用されているかを確認するときのテストスコープについて、ブラウザは[GoogleChrome][MicrosoftEdge][Firefox][Safari]をテスト対象と仮定し、各ブラウザのサイズや文字サイズ設定を変更しても問題ないか、さらに設定するウィンドウサイズは想定の最小値・最大値・全画面のパターンで、文字サイズは通常から何％拡大を対象とするかなどを考慮し、どの組み合わせでのテストを必要とするかを検討するといったような場合には、当該技法を用いることで視覚的に情報を整理しやすくなります。
1. システム要件の一例
Webサイトかスマホアプリから食事を注文すると自宅まで届けるサービスで、条件によって割引を適用するシステムの要件を定義します。
■食事配送サービスの割引システム仕様
・スマホアプリから注文の場合は合計金額から10％割引・土日祝日以外の注文は20％割引適用
・特別配布クーポンのクーポンコード入力をして6000円以上の注文をした場合は合計金額から2000円引き
・クーポンは各種割引とは併用不可
・スマホアプリの割引10％と平日割引の20％は同時に適用可能
2. 各要素の順序
各要素は木構造で上から下に向かって細分化するように図にしていきます。
最上位の要素はトップノードと呼び、テスト対象とするシステムそのものを配置します。
今回は割引が適用されるパターンについてテストしたいので、トップノードは[割引適用システム]とします。
次の要素はクラシフィケーションと呼び、システムに想定される変数やパラメーターを配置します。
割引が適用されるケースについて分けるので、[注文環境][曜日][クーポン有無]とします。
さらにその次の要素をクラスと呼び、変数やパラメーターの具体的な値を配置します。
・[注文環境]の場合
[スマホアプリ注文]で10％引き[Web注文]の場合は割引なし
・[曜日]の場合
[平日注文]で20％引き[土日祝注文]で割引なし
・[クーポン有無]の場合
[クーポン利用で合計6000円以上]注文の場合は2000円引き[クーポン利用で合計6000円以下]注文の場合はクーポンを消費せず値引きなし
[クーポンなし]の場合は値引きなし
・クラシフィケーションツリー
3. 各要素を区分する際の法則
クラシフィケーション技法で各要素を木構造に当てはめるときに、観点の抜け漏れやズレがないようにケースを作成するために、以下記載の各法則に則って要素を考慮します。
・一貫性の法則
各段階の要素は同一の原理に基づくものとして設けます。
割引適用の上記仕様では、割引が適用されるかされないかという原理に基づいて、クラシフィケーションを[注文環境][曜日][クーポン有無]としました。
・相互排除の法則
各要素は互いに排他的な関係を原則として設けます。
類似や重複の要素があると枝を分ける意味がなくなります。
・一致の原則
各要素自体の分割は想定される分岐を全て網羅していることとして設けます。
今回の仕様では割引や値引きの適用される条件は全部で[注文環境][曜日][クーポン有無]の3パターンになります。
・漸進の原則
トップノードからクラシフィケーション、クラシフィケーションからクラスと、上から下に向かって要素が分けられていることを原則とします。
[割引適用システム]→[注文環境][曜日][クーポン有無]、[注文環境]→[スマホアプリ注文][Web注文]のように順を追って入れ子になっている必要があり、[割引適用システム]の下が[スマホアプリ注文][Web注文]になると、他の横に並べる要素もクラシフィケーションを飛ばしたクラスを列記する形になってしまうので、適切ではありません。
4. テストケースと網羅率
ワンワイズ(各要素を必ず1つテストする)、ペアワイズ(各要素の1対1での組み合わせを必ず1回テストする)、全網羅(各要素で想定される全組み合わせをテストする)のいずれかから、テスト工数・テスト期間・求めるテスト粒度を考慮の上、網羅率を検討します。
今回は仮に全網羅した場合でクラシフィケーション図に反映します。
・全網羅でのテストパターン
全網羅でのテストケースは12パターンになりました。
それぞれの期待結果をチェックリスト形式で記載します。
5. 追記
今回作成したシステム要件を見ると、クーポン利用＋6000円以上の注文の場合のみ、そのほかの割引処理を除外して合計金額から2000円値引きするという仕様がやや条件を複雑にしていた印象があります。
クーポンコードを入力してクーポン使用可能のステータスになっていても、合計金額が6000円を超えなければクーポンが消費されない(使用されない)という仕様のため、[クーポン適用金額以下]と[クーポン未使用]はどちらも同じく2000円値引きがなしという結果を返します。
チェックリストでいうと、No.1の[Web][土日祝][クーポン利用で合計6000円以下]と、No.2の[Web][土日祝][クーポンなし]は、どちらも[割引／値引きなし]が期待結果となります。
割引値引きの条件ごとの適用状態のみを焦点にテストをするならば、上記の様に[クーポン適用金額以下]と[クーポン未使用]条件のみが違う項目は、期待結果が同一として項目をまとめることで、テスト工数を削減できます。
より現実的なユーザー動作を想定するならば、クーポンコードを入力した後で合計金額が6000円以下の場合は、クーポンが消費されずに次回合計金額が6000円を超えたタイミングまでクーポンは有効になっていなければなりません。
クーポン有効化後で6000円以下の決済を行った際に、値引きも適用されずに、かつクーポンが利用不可になるという動作が発生してしまうと、金銭的な不利益がユーザーに生じてサービスの評価を著しく落とす可能性があります。
No.1ではあくまでクーポンは有効でありながら値引きされていないこと、No.2ではそもそもクーポンの適用自体を行っていない前提であることを確認する項目になります。
このようにテスト技法でテストケースを整理した後で、より詳細なテストケースの検討調整は常に必要になります。