テスト設計をする際には、テスト技法を使うことで、効率的に効果的なテストケースを作ることができます。今回、本稿で紹介する技法となる「順序組み合わせテスト」と「波及全使用法：IDAU法」は、バージョンアップ開発や派生開発などで、テスト対象に変更が入ったときに役立つテスト技法です。本稿を読んだみなさんに現場で適用してもらいたいと考えているため、連載形式で具体例も織り交ぜてわかりやすく紹介していきます。連載は全部で8回を予定しています。前半の4回はこの技法の特徴や具体的な使い方を湯本から説明します。連載の後半では、後続研究として取り組んだ内容を武田から説明します。
第三回目となる今回は、順序組み合わせテストによるテスト設計の手順とルールを、具体例を使って説明していきます。
テスト対象のおさらい
連載の初回で、複数の処理を動かすテストとは何か？という説明をする際に、「ホテル予約のWebサイトで、予約したい部屋が空いていれば予約ができ、空きがなければ予約ができない」「予約は予約日の2日前であればキャンセルできる」という仕様項目を例にして説明を行いました。そして「キャンセルは誤って押してしまう場合があるため、キャンセルしたその日であれば、キャンセルを取り消すことができる」という仕様変更が入った状況を示し、この仕様変更は以下の3点が考えられるという説明をしました。
- キャンセル当日であれば、他の人が予約できないこと
- 翌日になれば他の人が予約できること
- キャンセルを取り消せば翌日になっても他の人はホテルの部屋の予約ができないこと
今回は、具体例として、予約したホテルの部屋のキャンセルに対してこれらの仕様変更が入ったときに「どこまでテストをすべきか？」という問いに対して、順序組み合わせテストとIDAU法を適用したテスト設計をしてみたいと思います。
変更タスクの特定
順序組み合わせテストで最初に行うのは、機能セットから変更タスクとそのデータストア（変更に影響を受けるデータの格納先）を特定することです。ホテル予約のWebサイトの例で示した「キャンセルしたその日であれば、キャンセルを取り消すことができる」）という仕様変更の場合は、「キャンセル取消」が変更タスク群に該当します。また「キャンセル」も、キャンセル当日か翌日かを状態で判断するタスクが入るので、変更タスク群の中に入るタスクでしょう。そして、それらはホテル空室予約というデータを更新します。図1が変更タスク群を特定したDFDになります。
図1 変更タスクの特定
キャンセルは、当日だと取消が可能であるため、他の人は予約ができない状態にしておかなければならなりません。翌日になると、キャンセルの取消はできなくなるため、他の人が予約可能な状態になります。キャンセルタスクによる状態の変化についてはDFDのデータストアの隣に記載しておきます。
明らかにした変更タスクは、表1の拡張CRUD図に記載していきます。
表1 拡張CRUD図（波及タスクまで記載済み）
| タスク | データストア | 源泉 |
| ホテル予約 | 予約サイト利用者 | |
| キャンセル | U | In |
| キャンセル取消 | U | In |
波及タスクの特定
順序組み合わせテストで次に行うのは、波及タスクの特定です。波及タスクは、変更タスクで操作するデータに対して操作をするタスクです。このタスクがどれになるかは、CRUD図を参照することで見つけることができます。その中から表2のタスク間のデータ共有組合せパターン（第二回で掲載したものと同様の表）に該当する組み合わせを波及タスクとして特定します。
表2 タスク間のデータ共有組合せパターン
| 変更タスク群 | |||||
| C：生成 | R：参照 | U：更新 | D：削除 | ||
| 波及 タスク 群 | C：生成 | × | × | × | ◯ |
| R：参照 | ◯ | – | ◯ | – | |
| U：更新 | ◯ | – | ◯ | × | |
| D：削除 | ◯ | – | ◯ | × | |
図2は、ホテル予約のWebサイトの例で波及タスクも含めたDFDになります。変更タスクであるキャンセル、キャンセル取消の両方がデータの更新をしており、かつ予約実行もホテル予約のデータを更新します。表2から、変更タスクがU:更新の操作を行い、後続するタスクがU:更新を行う場合は組み合わせ対象になるため、キャンセルの後続として行う予約実行は、波及タスクに該当します。また、予約のキャンセルやキャンセル取引は変更タスクであると同時に、後続して行われるU:更新をするタスクに相当するため、波及タスクに該当します。
図2 波及タスクの特定
図2と表2で明らかになった波及タスクを含めて記述した拡張CRUD図が表3になります。状態によってタスクの振る舞いが変化するため、タスクの後ろに状態を追記しています。
表3 拡張CRUD図
| タスク | データストア | 源泉 |
| ホテル予約 | ホテル予約者 | |
| キャンセル | U | In |
| キャンセル取消 | U | In |
| 予約実行［取消可能状態］ | U | Out |
| 予約実行［取消不可状態］ | U | Out |
| キャンセル | U | Out |
| キャンセル取消［取消可能状態］ | U | Out |
| キャンセル取消［取消不可状態］ | U | Out |
組み合わせの特定
変更タスクと波及タスク、タスクが行う操作が明らかになったので、組み合わせを行います。源泉にInと書かれているものを最初に操作するタスク、Outと書かれているものを後続のタスクとして組み合わせを列挙します。ホテル予約サイトの仕様変更の例で列挙した組み合わせた結果は表4で確認できます。データストアに対する操作の組み合わせは、この例では全てがUであるため、変更タスクと波及タスクの組み合わせから増えることはありません。注記しておきたいのは、拡張CRUD図からリストする際に変更タスクと波及タスクが同じタスクの場合の考え方です。IDAU法では同じタスクの同一処理の組み合わせに関してはカバレッジ基準に含めないとしています。ただし、現実的には同じ処理を複数回やってみてどうなるかというテストが必要になる場合もあるため、テストケースとして追加しても問題ありません。
表4 変更タスクと波及タスクの組み合わせ
| No | 変更タスク | 波及タスク | テスト対象の仕様項目 |
| 1 | キャンセル | 予約実行［取消可能状態］ | キャンセル当日は他の人が予約をできないこと |
| 2 | キャンセル | 予約実行［取消不可状態］ | キャンセル翌日は他の人が予約をできること |
| 3 | キャンセル取消 | 予約実行 | キャンセル取消をしたら、予約状態になるので、翌日以降でも他の人が予約をできないこと |
| 4 | キャンセル | キャンセル取消［取消可能状態］ | キャンセル当日はキャンセル取消ができること |
| 5 | キャンセル | キャンセル取消［取消不可状態］ | キャンセル翌日はキャンセル取消ができないこと |
| 6 | キャンセル取消 | キャンセル | キャンセル取消の後は、キャンセルができること |
ホテル予約Webサイトの例では、6つの処理の順序組み合わせを特定できました。これらをテストケースにしてテスト実行をしていきます。
まとめ
今回は、順序組み合わせテストとIDAU法というテスト技法について説明をする連載の第三回目として、「順序組み合わせテスト」によるテスト設計の手順とルールをホテル予約サイトで発生した仕様変更という題材を使って具体的に説明しました。「順序組み合わせテスト」は、データを介す処理同士をつなげてテストケースにしていく技法であるため、例で示したようなデータベースを内部に持つことが多い業務系の情報システムがより適しています。そのため、組み込みソフトウェアのような制御専門のソフトウェアでは、あまり適用の効果が出ません。ただし、昨今の組み込みソフトウェアは、IoTのように、デバイス同士がつながって利用者に価値を提供するようなシステムに組み込まれることが多くなり、そうなると必ずデータを介した処理が出てくるため、組み込みソフトウェアの領域でもこの技法が活用できる状況は多くなっていくと考えられます。
次回は、変更タスクと波及タスクの特定に関して、第一回で示したホテル予約のWebサイトの例を使って詳しく書いていきたいと思います。
第1回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第2回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第4回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第6回：波及全使用法(IDAU)をソースコードレベルのテストに応用したコードベースド波及全使用法(CB-IDAU)
