テストタイプの設計アプローチ(標準規格の品質モデルで分割してはいけない)

 特定のテストレベル(例えばシステムテスト)で大規模で複雑なテストを設計する場合、目的や十分性基準、テスト設計方針を具体的に考えるために、関心事の分離を実施する必要があります。
 その手段の一つとして、テストタイプの設計があります。そこでは巨大なテストの活動をテストタイプに分割することによって、テストタイプごとに関心事を分けて活動を進められるようにします。

まずいアプローチ:品質モデルの標準規格そのままに分割する

 このテストタイプの設計手段ですが、ISO25010といった標準的な品質モデルをそのままテストタイプの切り分け方に適用するアプローチをしばしば見ます。
 例えば、ISO25010の主特性「機能適合性」「性能効率性」「互換性」「信頼性」「セキュリティ」「移植性」をそのまま使って、テストを「機能適合性テスト」「性能効率性テスト」「互換性テスト」「信頼性テスト」「セキュリティテスト」「移植性テスト」に分ける、というアプローチです。

 ただこれは不適切なアプローチです。
 標準規格の品質モデルは、テスト活動のやりやすさを考慮して分けられたものではありません。さらにあくまで標準的なモデルであり、実際のあるべき品質モデルはプロジェクトや開発物によって大きく異なります。そのため標準規格の品質モデルでテスト活動を区分けしようとすると、以降のテスト活動にて、分析作業の重複が多発するなどといった支障が発生します。

有効なアプローチ:テスト対象に適した品質モデルと、テスト活動のやりやすさを観点に設計する

 ではどうするかについてですが、テストタイプの導出は、テスト対象に適した品質モデルの観点を分析するのがメインアプローチになります。
 それに加えて、以降のテスト活動が実施しやすいか」の観点を使ってテストタイプを具体化・調整していくのが有効です。この「以降のテスト活動が実施しやすいか」のより具体的な観点をいくつか以下に記載します。

「テスト分析・テスト設計がしやすいか」

 例えば、テスト分析を行えるサイズまで、テスト観点あるいはテスト条件をテストタイプとしてグルーピングするという観点です。大規模で複雑なテストは、テスト観点あるいはテスト条件も膨大かつ複雑で、そのままではテスト分析が困難です。それを扱えるサイズまでパッケージングできれば、以降のテスト分析も容易になります。

 また、テスト分析・テスト設計の担当の能力に合わせて、テストタイプを分割するというのも、この観点の主要なアプローチです。
 例えばセキュリティテストだけ特別なスキルを持つある専門チームでしかテスト設計できないならば、セキュリティテストとそれ以外のテストをテストタイプとして分割することで、プロジェクトが以降の作業を効率的に進められるようになります。

 さらに、テスト分析・テスト設計を行うタイミングに合わせて、テストタイプを分割するのも、この観点に基づいた設計アプローチです。
 例えばテスト分析・テスト設計に必要なインプット情報の入手時期が大きく異なるならば、早期に扱うテストタイプ、後期に扱うテストタイプと、入手時期ごとに分割することで、時期に応じてテスト設計アプローチを変える対応が可能になります。

 設計・実装のアプローチに合わせて、テストタイプを配置するという観点もあります。
 例えばユーザストーリをベースに開発しているならば、ユーザストーリテストと、それを補完するテストにテストタイプを分割することで、ユーザストーリ単位の開発アプローチを支えつつ、補完的な品質保証を実施するアプローチを容易に遂行できるようになります。

「テスト実施がしやすいか」

 例えば、必要なテスト環境・テスト機材に応じて、テストタイプを分割するアプローチです。
 特殊なテストラボでしか実施できないテストがあるならば、特殊なテストラボで実施するテストタイプと、それ以外のテストタイプを分割することで、テスト実施環境に合わせたテスト活動を円滑に遂行できるようになります。

 テスト実施のサイクルやタイミングに合わせて、テストタイプを分割するのもこの観点の一種です。例えば1週間のスプリントごとに実施するユーザストーリテストと、1か月程度のリリースサイクルごとに実施するリリーステストがあれば、そのサイクルを基準にテストタイプを分割すると、サイクルに応じたテスト活動方針の最適化が容易になります。

テストタイプ間の連携をどうするか

 テストタイプの設計で関心事の分離を推進した場合で課題となるのが、テストタイプ間の連携です。
 
 テスト活動は全体として品質保証を達成する必要があり、テストタイプの組み合わせに漏れがあると問題が発生します。また無駄なリソースやコストを軽減するために、テストタイプ間の重複のムダは、少ないほうが良い場合が多いです。さらに困難なテストの課題に対応する際は、それぞれのテストタイプの強みを活かすように、テストの重ねわせやテストの連携協力が求められます。

 そのため、テストタイプを分割すれば、あとはバラバラに活動すれば良いというわけではなく、分割後もテストタイプ間で相互連携をしながらテスト活動を推進する必要があります。

 この連携の管理方法ですが、有効なものにテストタイプの分割アプローチのモデリングがあります。例えば「GSNでテストタイプを分析する - 千里霧中」で紹介したGSNによってテストタイプ設計のアプリーチをモデル化しておくと、テストタイプそれぞれが全体の中でどのような責務を持っているか明確になります。またあるテストをどのテストタイプで実施すべきかの判断フロートしてもモデルを活用できます。

 また課題やリスクのコントロールとして、テストタイプをどのように連携させるか管理するアプローチも有効です。例えば「テストを導くためのテストアーキテクチャの組み立て方/cetam - Speaker Deck」で紹介しているリスクコントロールとしてテストタイプをどのように組み合わせるかを管理しておくと、テストタイプがどのテストタイプとどのように連携すべきかを明示できるようになります。