※本記事は登録会員限定記事ですが、現在限定公開中です。
テスト設計をする際には、テスト技法を使うことで、効率的に効果的なテストケースを作ることができます。今回、本稿で紹介する技法となる「順序組み合わせテスト」と「波及全使用法：IDAU法」は、バージョンアップ開発や派生開発などで、テスト対象に変更が入ったときに役立つテスト技法です。本稿を読んだみなさんに現場で適用してもらいたいと考えているため、連載形式で具体例も織り交ぜてわかりやすく紹介していきます。連載は全部で8回を予定しています。前半の4回はこの技法の特徴や具体的な使い方を湯本から説明します。連載の後半では、後続研究として取り組んだ内容を武田から説明します。
第一回目となる今回は、まず、一般的なテスト技法についての前提知識をおさらいした上で、同値分割法のようなテスト技法が対象にしているテストと、今回紹介する技法が対象にする「複数の処理を動かす」テストの違いを具体例と一緒に説明します。そして複数の処理を動かすテストがどのような時に役立つかについて説明します。最後に、今回紹介する技法の概要を、複数の処理を動かすテスト技法である状態遷移テストとの対比で説明したいと思います。
テストケースとテスト技法
テスト技法を使うテスト設計のアウトプットはテストケースです。ISTQB用語集では、テストケースという用語は以下のように定義されています。
| 実行事前条件、入力値、アクション（適用可能な場合）、期待結果、および実行事後条件のセットであり、テスト条件に基づいて開発されたもの。（ISTQB用語集） |
図1は、テストケースの構成要素をクラス図の表記で図解したものです。実行事前条件や入力値は、合わせてパラメーターと呼ぶことができます。テスト技法は、テストケースの要素のうち、パラメーターのバリエーションをどこまでカバーすべきか決める際に有用な技術になります。
テスト設計で使う一般的なテスト技法をパラメーターのバリエーションの特定の仕方で説明すると、以下のようになります。
- 同値分割法、境界値分析→パラメーターと値（P-V）を特定する
- デシジョンテーブルテスト→期待結果を導くパラメーターセットを特定する
- ペアワイズテスト→パラメーターと値（P-V）の組み合わせパターンを特定する
- 状態遷移テスト→実行事後条件を導く実行事前条件（パラメーター）を特定する
同値分割法、境界値分析、デシジョンテーブルテスト、ペアワイズテストは、入力値のバリエーションに着目しています。そのためテスト実行の際には、一つの処理を動かすことで確認ができます。
一方、状態遷移テストは、上記した技法とは異なり、実行事前条件に着目しています。テスト技法によって導かれるのは入力の組み合わせではなく、ある処理に対する操作とその前後の状態になります。実行事前条件が異なる際の処理の結果は、同じ入力値を用いても、異なる出力結果になることがあります。実行事前条件が異なるようにするためには、事前に何かしらの処理を動かしています。そのため、複数の処理を操作する手順の組み合わせを考慮してテストを実行していき、その結果を確認する必要があります。この複数の処理を操作する手順を組み合わせたテストを設計する際に使うのが状態遷移テストです。状態遷移テストをする場合、テスト実行の際には複数の処理を動かして確認することになります。
複数の処理を動かすテストとは？
複数の処理を動かして確認する必要がある場合にはどのようなものがあるかを例示します。例えば、ホテル予約のWebサイトで、予約したい部屋が空いていれば予約ができ、空きがなければ予約ができない、といった仕様項目をテストするとします。この場合のテストは表1に示した２つが考えられます。
表1 「予約実行」のテストケースの例
| 実行事前条件 | アクション | 期待結果 | |
| テストケース1 | 部屋が空室の状態 | 予約実行 | 予約成立 |
| テストケース2 | 部屋が予約済の状態 | 予約実行 | 予約不可 |
表2 「予約キャンセル」のテストケースの例
| 実行事前条件 | アクション | 期待結果 | |
| テストケース1 | 部屋の予約2日前 | キャンセル実行 | キャンセル成立 |
| テストケース2 | 部屋の予約1日前以降 | キャンセル実行 | キャンセル不可 |
予約をキャンセルした後であれば、別の人がその部屋を予約できなければならないはずです。そのような場合は、2つの表に示したテスト以外に、予約のキャンセル処理を行い、その後に予約実行処理を行うテストが必要になります。
上記の仕様項目では、複数の処理を動かすとどうなるかは明示していませんでした。もし、予約実行と予約キャンセルを別の人が開発していたとしたら、予約キャンセル処理が予約実行へ影響を与える（波及する）ことに対する考慮漏れをしてしまい、期待通りに動作しない可能性があります。
バージョンアップや派生開発の時に役立つ
バージョンアップ開発や派生開発などで、テスト対象に変更が入ったときは、この「複数の処理を動かして確認するテスト」が役立ちます。変更が入った箇所はしっかり考慮していても、その変更が変更箇所以外にも波及するかどうかを考えないことが多いためです。
例を挙げてみます。予約したホテルの部屋のキャンセル処理に仕様変更が入ったことを想定してください。たとえば、「キャンセルは誤って押してしまう場合があるため、キャンセルしたその日であれば、キャンセルを取り消すことができる」という仕様変更が入ったとします。この場合、その日のうちであればキャンセルが取り消せることをテストしなければなりません。
しかし、キャンセル取り消しのテストをすれば十分でしょうか？仕様変更が変更箇所以外にも波及するかを考慮して、必要であればテストをしなければなりません。例えば以下のようなことが考えられます。
- キャンセル当日であれば、他の人が予約できないこと
- 翌日になれば他の人が予約できること
- キャンセルを取り消せば翌日になっても他の人はホテルの部屋の予約ができないこと
複数の処理を動かしてテストするための設計技法
前述したとおり、複数の処理を動かしてテストする技法には状態遷移テストがあります。
状態遷移テストは状態の変化に着目し、状態が変わるイベント（イベントは処理であることが多い）をつなげてテストしていく方法です。図2を使って説明すると、処理2を実行した際の出力結果を確認することで、状態1が状態2になっていると判断することができます。
状態遷移テストでは、何を状態とするかで予約実行と予約キャンセルの２つの処理を順番に実行するテストケースが抽出できるかどうかが変わります。ホテル予約のWebサイトを例に具体的にすると、予約画面やキャンセル画面といった画面を状態とする場合、予約画面とキャンセル画面への遷移が隣接していなければキャンセルした後に予約をするというテストケースが見つからない可能性があります。画面遷移のつながりを全てテストするとなると、予約とキャンセルのテスト以外もカバレッジ対象になってしまい、テストケース数が膨大になる可能性があります。
「データを介してつながる処理を組み合わせる」という考え方で、状態遷移テストとは別の処理順序を組み合わせるテスト技法が順序組み合わせテストです。同じデータを介して複数の処理がつながるところに着目し、そこだけをテストの対象にします。
順序組み合わせテストとIDAU法
それでは、順序組み合わせテストとそのカバレッジ基準であるIDAU法の説明をしていきます。順序組み合わせテストでは、図3で示すとおり、ある処理と別の処理がデータを介しているかどうかに着目します。
ホテル予約のWebサイトの例で具体的に説明します。このWebサイトが持つデータベースには、部屋というエンティティがあり、処理をする際に部屋エンティティに対して新しいデータ（複数の情報である可能性もある）を登録したり、そのデータの内容を書き換えたり、そのデータの内容を参照したりできるとします。
バージョンアップや派生開発の場合は、変更対象となる処理があります。ホテル予約のWebサイトの例では、「キャンセルの取り消し」が変更対象となる処理に該当します。この処理が部屋エンティティに対して影響を与えるのであれば、影響を受けたデータを介して行われる部屋の予約処理を抽出してテストを行います。
順序組み合わせテストは、処理順序を組み合わせる際にデータに着目し、そのデータフローをテストしているとも言えます。
一般的なデータフローテストのカバレッジ基準である全使用法（AU法）の定義は「データを定義したすべての場所から始まり、データを使用するすべての場所に至るまでのパスセグメントの最低限１つを含むテストケース」となります。この定義を変更対象の処理とデータを介して影響を受ける処理との関係に置き換えて「変更タスクから始まり、変更タスクにおいてデータの生成および更新があるデータを使用する波及タスクを実行するまでのパスセグメントを、経由するルートにかかわらず最低限１つ含むテストケース」というカバレッジ基準にして、波及全使用法(Impact Data All Used : IDAU)と命名しました。（変更タスクと波及タスクについては第二回に詳しく説明します。）
まとめ
今回は、順序組み合わせテストとIDAU法というテスト技法について説明をする連載の第一回目となるため、一般的なテスト技法についての前提知識をおさらいした上で、この技法の概要を説明しました。また、この技法がどのような時に役立つかについても触れました。次回は、技法の使い方を順序立てて詳しく説明していきます。
第2回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第3回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第4回：バージョンアップ開発や派生開発のときの影響範囲をテストしていますか？
第6回：波及全使用法(IDAU)をソースコードレベルのテストに応用したコードベースド波及全使用法(CB-IDAU)
