テストケースの粒度の話を覚えていますか。「○○というユーザ名、××というパスワードでログインする」というテストケースに対して、「ログインする」というテストケースは粒度が粗い、という話でしたね。

仮に自分の組織のテストケースが前者の粒度だったとしましょう。もしユーザ権限が4つあった場合は、それぞれの権限に合わせたアカウントで、最低でも4種類のテストケースを作成することになります。では逆に、権限の異なる4つのテストケースをレビューすることになったら、皆さんはどうしますか？

まず4つのテストケースの違いを考えますね。ふむふむ、ユーザ名が違うなぁ、なぜ違うんだろう、と考えながら仕様を思い出したり、仕様書をめくったりします。なるほど、ユーザ権限が異なるわけか、では必要な権限は網羅されているかな、なんて考えながらレビューしていくと思います。面倒ですね。

では、4つのテストケースに対して「すべての権限のアカウントでログインするためのテストケースです。この4つはセットです。」という注意書きがついていたらどうでしょう。テストケースのレビューがとても楽になります。テストケースを考えた担当者の思考プロセスを追うことができますから。

言い換えると、テスト担当者は「すべての権限のアカウントでログインする」という粒度の粗いテストケースをまず考えて、それから4つの粒度の細かいテストケースを導き出したわけです。テストケースを漏れなく考えるためには、粒度の粗いテストケース（すべての…ログインする）をまず考えて、制約条件（権限は4種類）を挙げ、粒度の細かいテストケース（○○というユーザ名…ログインする）に詳細化すると便利です。これを私はテストの「設計」と呼んでいます。またテスト設計の中間成果物を示すと、テストのレビューが容易になってテスト漏れを防ぎやすくなります。

テストの設計を行うと、仕様変更に強いテストケースができますね。テスト設計をせずに細かいテストケースを一つ一つ挙げるだけだと、要求事項の変更に関係するテストケースが分かりにくくなってしまいます。先ほどの例で、権限が3種類に減ったらどうやってテストケースを変更すればよいでしょうか。4つのテストケースを全て見直さなくてはなりません。しかしテスト設計を行うと、それぞれの詳細化のプロセスで考慮する制約条件が明示されますから、全て見直す必要は無くなり、仕様変更によるテストのモレやムラは減りやすくなります。

仕様変更に強いということは、再利用が楽になるということです。再利用した要件と変更した要件の差をきちんと認識しておけば、再利用できるテストケースの粒度と、再設計が必要なテストケースの粒度を分けることができます。先ほどの例で、新しいシステムでログイン手段がキーボード入力でなく指紋認証になった場合でも、粒度の粗いテストケース（すべての…ログインする）はそのまま流用できます。

ちなみに私は、最も細かい粒度のものをテストケース、テストケースよりも粗いものをテストアイテムと呼んで区別しています。テストアイテムには何レベルも粒度がありますね。何をどう呼ぶかは好みですが、テスト設計だけは忘れないようにして下さい。