衣類を販売するECサイトで、トップスの購入金額とボトムスの購入金額を合計し、合計金額が一定の金額以上になった場合は特別割引クーポンを配布するというシステムの要件を定義します。

■合計金額でクーポンを配布するシステムの仕様

　・トップス商品カテゴリ内の最低金額は1000円

　・ボトムス商品カテゴリ内の最低金額は1500円

　・クーポン配布対象になる最低合計金額は3500円から

　・どちらかのカテゴリのみで最低合計金額を超えてもクーポン配布対象にはならないものとする

ドメイン分析テストでは、分岐の発生する境界値をon,off,in,outで分類します。

クーポン対象合計金額数値を例にします。

x >= 3500

onは有効同値側の境界値です。

クーポン配布対象の最低合計金額は3500円からという仕様なので、有効同値となるonの数値は[3500]になります。


offは無効同値側の境界値です。

上記の仕様から無効同値となるoffの数値は[3499]になります。


inは有効同値パーティション内の任意数値です。

トップス・ボトムス・合計金額ともに上限値は設けていないので、特に制約はなく任意数値を選択します。


outは無効同値パーティション内の数値です。

合計金額[3499]以下はクーポン対象になりません。

トップス商品1品の最低価格は[1000]、ボトムス商品の最低価格は[1500]なので、想定可能な合計金額の最低値は1000 + 1500 = [2500]になります。

[3499]～[2500]の間であれば無効同値パーティション内なので、上記数値の中から任意数値を選べば良いですが、想定される下限値は[2500]なのでoutは[2500]としておきます。


そのほか各条件も境界値分析を元にon,off,in,outを想定します。

トップス・ボトムスのoff条件については、商品としてサービス内に存在しない数値なので数値設定不能ですが、「どちらかのカテゴリのみで最低金額を超えてもクーポン配布対象にはならない」という仕様があるので、[購入しない]というステータスをoffの数値として設定します。

■トップスカテゴリ境界値

　・on[1000]

　・off[購入しない]

　・in[任意]

　・outはoff同様に購入しない想定としてoffと条件が変わらないので除外

■ボトムスカテゴリ境界値

　・on[1500]

　・off[購入しない]

　・in[任意]

　・outはoff同様に購入しない想定としてoffと条件が変わらないので除外

■合計金額境界値

　・on[3500]

　・off[3499]

　・in[任意]

　・out[2500]

上記各数値を元に、表の形式で各パターンを整理します。

まずはBinderのドメイン分析テストマトリクスを参照します。

・Binderのドメイン分析テストマトリクス

1列目は、Xのon動作を確認するため、yとzは有効同値パーティション内の任意数値であるinを使用するという表記になっています。

こちらの表を元にして、今回のケースに併せて各項目を調整します。

・調整後のドメイン分析テストマトリクス

outは本来無効同値内の任意数字であり、条件外の確認はOFFの無効同値自体で確認できているので、確認は不要になるものですが、今回のケースにおける合計金額の無効同値内任意数値は、システムの仕様として実行可能な最低値[2500]が存在するため、トップスとボトムス両方を購入するという条件を満たしたうえでさらに無効同値内の再現可能な最低値として、表内に追加しています。

テストに使用するチェックリストの形式にするため、任意で設定していた箇所に具体的に数値を設定し、合計金額とトップス・ボトムス両方購入フラグの欄を設けて、テストケースとして不足がないかを確認します。

・テストケース

任意としていた金額には、いったん[50000]を設定しています。

トップス・ボトムス・合計金額ともに特に上限値は設けてはいないため、任意数値の[50000]という数字に特に根拠はありません。

各数値と確認対象となる挙動を整理した結果として、各項目で以下の通り想定パターンを網羅していることが確認できました。


　・No.1,3,5
　合計金額の判定条件と両カテゴリ購入の判定条件をどちらも満たしている場合

　・No.2,7
　両カテゴリ購入の判定条件は満たしているが合計金額の判定条件を満たしていない場合

　・No.4,6
　合計金額の判定条件は満たしているが両カテゴリ購入の判定条件を満たしていない場合


以上で各条件に想定されるon,off,in,outの境界値を組み合わせたテストケースを整理できました。

記事として取り上げるテスト技法を軸に、サンプルとして適切なシステム仕様を仮作成して、実際に技法を用いてテストケース作成に至る状態まで進めてみましたが、on,off,in,outと関係する要素の数が多すぎず少なすぎずちょうど簡潔になる程度にケースを考慮するのがなかなか困難でした。

今回サンプルとして作成したケースを顧みると、outが実際のユーザー操作として実現可能なもののため、Binderのドメイン分析テストマトリクスを元に、表内にoutの行を追加調整する対応を行いました。


このドメイン分析テスト技法に限らず全てのテスト技法に共通して言えることですが、開発仕様を元に適切な技法を用いてテストケースを効率よく作成する必要があるものの、システムの要件はユーザーに提供されるサービスやシステムを想定して作成するものであり、ケースごとに要求される内容はさまざまです。

必ずしも定量的に分析できるものではなく、使おうとしている技法にちょうど合致するような開発仕様になるとは限らないため、どのようなテスト技法を用いるか、テンプレートからどのような変更調整が必要かなど、状況に応じて柔軟に対応することを心がけたいものです。


むしろ開発仕様自体に曖昧であったり不完全な部分がある場合に、テスト技法やテンプレートと照らし合わせる過程で疑問や指摘事項を検出することもままあるので、テスト技法の知識技術を仕様自体の静的テスト(レビュー)として用いることで、効率的で高品質なソフトウェアテスト実現の一助になると思います。