TM-2.4.3 (K2)テスト戦略のテスト活動に対する影響を、例を示して説明する。

分析的戦略

テストチームはテストベースを分析して、カバーするテスト条件を識別する。

例)
要件ベースドテストでは、テスト分析により要件からテスト条件を導き出し、これらの条件をカバーするようにテストを設計し実装する。
その後、各テストによりカバーする要件の優先度に基づいて、テストを実行する順序を決め、テストを実行する。
テスト結果は、たとえば、要件をテストし合格した、要件をテストし不合格となった、要件をまだ完全にテストしていない、要件のテストがブロックされている、などの要件のステータスに関してレポートする。

モデルベースド戦略

テストチームは(実際の状況または予想される状況に基づいて)、システムが存在する環境、システムに対する入力と条件、および本来のシステムの動作方法の各モデルを作成する。

例)
急成長のモバイルデバイスアプリケーションのモデルベースド性能テストでは、現在の使用状況と今後の想定される伸び具合に基づいて、受信と送信のネットワークトラフィック、アクティブユーザと非アクティブユーザ、および結果的に生じる処理負荷の各モデルを開発する。さらに、現在の本番環境のハードウェア、ソフトウェア、データ容量、ネットワーク、およびインフラストラクチャを考慮してモデルを開発する場合がある。また、スループット、応答時間、およびリソース割り当てに関して、理想的なモデル、予想されるモデル、および最小モデルを作成することも可能である。 

方法論的戦略

テストチームは品質標準(たとえば ISO 9126など)の事前に決定した一連のテスト条件、チェックリスト、あるいは特定のドメイン、アプリケーション、またはテストのタイプ(たとえばセキュリティテストなど)に関連する汎用的かつ論理的な一連のテスト条件を使用する。

例)
シンプルで安定した e-コマース Web サイトの保守テストでは、テスト担当者は主要な機能、属性、および各ペー ジに対するリンクを識別するチェックリストを使用する場合がある。テスト担当者は、このサイトに対して変更を行うたびに、このチェックリストの関連する要素をカバーする。

プロセス準拠または規格準拠戦略

テストチームは規格委員会または他の専門家達が定義した一連のプロセスに従う。このプロセスでは、文書化、テストベースとテストオラクルの適切な識別と使用、およびテストチームの編成を行う。

例)
スクラムアジャイルマネジメント技法に準拠するシステムでは、テスト担当者は各イテレーションにおいて、 特定のフィーチャを説明するユーザストーリーを分析し、そのイテレーションの計画作業プロセスの一環として各フィーチャのテスト工数を見積り、各ユーザストーリーに対するテスト条件(通常、受け入れ基準と呼ばれる)を識別し、これらの条件をカバーするテストを実行して、テスト実行時の各ユーザストーリーのステータス(未テスト、不合格、または合格)を報告する。

対処的戦略

テストチームはソフトウェアを受け取るまでテストの設計と実装を待ち、テスト対象の実際のシステムで対処する。

例)
メニューベースアプリケーションで探索的テストを使用する際は、フィーチャ、メニューの選択、および画面に対応する一連のテストチャータを開発する。各テスト担当者には一連のテストチャータが割り当てられ、それを使用して探索的テストセッションを構築する。テスト担当者はテストセッションの結果を定期的にテストマネージャに報告し、その結果に基づいてテストマネージャはチャータを変更する場合がある。

コンサルテーションベースの戦略

テストチームは一人以上の主なステークホルダの入力に依存して、カバーするテスト条件を決定する。

例)
Webベースアプリケーションのアウトソース互換性テストでは、企業はアウトソーステストサービスプロバイダに、評価するアプリケーションの優先度付けしたリストを提供する。このリストには、ブラウザバージョン、マルウェア対策ソフトウェア、オペレーティングシステム、接続の種類、およびその他の構成オプションを含む。テストサービスプロバイダはペアワイズテスト(優先度が高い場合)、同値分割法(優先度が低い場合)などの技法を使用して、テストを生成する。

回帰的テスト戦略

テストチームは回帰のリスクをマネジメントするさまざまな技法(特に 1 つ以上のレベルにおける機能/非機能回帰テストの自動化)を使用する。

例)
Webベースアプリケーションの回帰テストを行う場合、テスト担当者はGUIベースのテスト自動化ツールを使用して、アプリケーションの一般的および例外的なユースケースを自動化する。これらのテストを、アプリケーションの変更時に常に実行する。

例題