例えば、「この hotfix をリグレッションテストして」と言われたとします。でも、ちょっと待ってください。そのホットフィックスは、データを広範囲で破壊する可能性のある修正だとしたら、はたしてリグレッションテストだけでテストは完了するでしょうか。ホットフィックスなので、急いで直したいものではあるのですが、影響の大きなもののテストを、リグレッションテストだけで終わらせるのは、危険が大きいでしょう。
テストの性能とは
ここで、もしリグレッションテストのカバレッジが、十分に網羅性の高い物なら良いのかもしれません。ですが、網羅性の高いリグレッションはメンテナンスコストが高く、網羅的なものよりは、よく使う遷移や重要な操作などの、リスクを避けるような作りになっているかもしれません。リグレッションテストだけで、テスト充分性が担保できているかは、ポリシーとリソース次第です。
こういった、手持ちのリグレッションテストセット（テストスイート）の、内容によっては、テストが足りず、さらに事故になる可能性があるかどうかを判断して、進める必要があります。この判断基準の一つになるのが、テストの性能です。
テストのポリシーとは
例えば、現在使っているリグレッションテストが、
- 最低限のユーザーが良く使う操作だけで構成されている
- 分岐のオプションをすべて網羅している
の、いずれかによって、リグレッションテストの性能と呼べるものは変わってきます。前者なら、「ユーザーのビジネスが止まらない程度の最低限の保証ができる」性能のテストといえますし、後者なら、「オプションを一通り網羅しつつも、メンテナンスがきっちりできていないと網羅性の保証がしかねる」性能のテスト、と言えるでしょう。
この、テストを行った後にどういう品質が担保できるか、ということを説明できるかどうかがポイントになります。
品質のコントロールがしやすくなる
テストのポリシーが説明できるということは、それに合致したテストの目的も説明できるようになります。そして、テストの性能を組み合わせてテストセットを構成すれば、テスト全体を説明できるようになります。
このマップは、それぞれ目的をもったテスト群で構成されています。これらで、クライテリアをコントロールしています。この、テストの性能が調整できるというのは、よくいわれる、説明責任を果たせる、ということでもあります。
つまり、テストの性能とは
こんな風に、一口にテスト、といっても、テストケースの意図によって、その期待できる保証内容は全然変わります。これを私は、テストの性能（保証できる内容）、と呼んでいます。