Loading article…
テスト戦略とは、ソフトウェア開発サイクルにおけるテスト手法を記述した概要です。テスト戦略の目的は、組織の高レベルな目標から、品質保証の観点からそれらの目標を達成するための実際のテスト活動へと、合理的な推論を提供することです。テスト戦略の作成と文書化は、すべての目標が網羅され、すべての関係者に理解されるように、体系的に行う必要があります。また、組織と製品が時間の経過とともに進化するにつれて、テスト戦略は頻繁にレビュー、検証、更新されるべきです。さらに、テスト戦略は、用語、テストおよび統合レベル、役割と責任、トレーサビリティ、リソースの計画などに関して、品質保証に関わるさまざまな関係者の認識を一致させることも目指すべきです。
テスト戦略とは、テストレベルでステークホルダーの製品リスクをどのように軽減するか、どのような種類のテストを実施するか、そしてどのような開始基準と終了基準を適用するかを記述したものです。これらは開発設計文書に基づいて作成されます。主にシステム設計文書が使用され、場合によっては概念設計文書が参照されることもあります。設計文書には、今後のリリースで有効化されるソフトウェアの機能が記述されています。開発設計の各段階ごとに、新しい機能セットをテストするための対応するテスト戦略を作成する必要があります。
テストレベルとは、ソフトウェア開発ライフサイクルにおけるテスト活動の範囲と焦点を定義するものです。テストレベルは通常、階層的に構成され、各レベルはテスト対象システムの異なる側面を対象とします。
一般的なテストレベルには、単体テスト、統合テスト、システムテスト、システム統合テストなどがあります。
単体テストは、個々のコンポーネントまたはモジュールを単独で対象とすることに焦点を当てています。
統合テストは、統合されたコンポーネント間のインターフェースとデータ交換を検証します。エンドツーエンドの統合テストは、API呼び出し、データベース操作、および選択的なユーザーインターフェーステストを使用して、システム全体の機能性を検証し、テクノロジースタック全体を対象とします。
システムテストとは、完全に統合されたシステムを、規定された要件に照らし合わせて評価するものです。
システム統合テストは、複数の統合システム間の相互作用をテストする。
組織やプロジェクト構造によって、各テストレベルの責任分担は異なります。一般的には開発者が単体テストを担当し、システムレベルのテストは専門のテストチームが担当することが多いです。
このセクションでは、テストリーダー、個々のテスター、およびプロジェクトマネージャーの役割と責任をプロジェクトレベルで明確に定義する必要があります。担当者の名前を明記する必要はありませんが、役割は非常に明確に定義されていなければなりません。
テスト戦略は開発者によるレビューを受けるべきです。また、テスト範囲が完全でありながら重複していないことを確認するため、すべてのレベルのテストリーダーによるレビューも必要です。テストを開始する前に、テストマネージャーと開発マネージャーの両方がテスト戦略を承認する必要があります。
環境要件はテスト戦略の重要な要素です。テストに使用するオペレーティングシステムを記述し、必要なOSパッチレベルやセキュリティアップデートについても明確に示します。例えば、特定のテスト計画では、テストの前提条件としてWindows 8.1のインストールが必要となる場合があります。
テストケースの実行方法には、手動テストと自動テストの2種類があります。テストの内容にもよりますが、通常は手動テストと自動テストを組み合わせるのが最適なテスト方法です。
テストプロセスに影響を与える可能性のあるリスクはすべて、その軽減策とともにリストアップする必要があります。リスクを文書化することで、その発生を事前に予測できます。リスクの発生を未然に防いだり、被害を軽減したりするための予防措置を講じることも可能です。リスクの例としては、下請け業者によるコーディングの完了状況への依存や、テストツールの性能などが挙げられます。
テスト計画では、テストフェーズの完了にかかる時間を見積もる必要があります。テストフェーズを完了するには、多くの要件があります。まず、テスターはすべてのテストケースを少なくとも1回実行する必要があります。さらに、欠陥が見つかった場合は、開発者がその問題を修正する必要があります。その後、テスターは、失敗したテストケースが正しく機能するまで再テストする必要があります。最後に、テスターはサイクルの終わりに回帰テストを実施し、開発者がソフトウェアの別の部分を修正する際に、誤って別の部分を壊していないことを確認する必要があります。これは、以前は正しく機能していたテストケースでも発生する可能性があります。
テストスケジュールには、テストを実施できるテスターの人数も記載する必要があります。可能であれば、各テスターにテストケースを割り当ててください。
テスト段階には多くの不確実性が伴うため、テストスケジュールを正確に見積もることはしばしば困難です。計画担当者は、予期せぬ問題に対応するために必要な追加時間を考慮に入れる必要があります。この見積もりを行う一つの方法は、ソフトウェアの過去のリリースで要した時間を参考にすることです。ソフトウェアが新規の場合は、初期テストスケジュールの見積もりを2倍にするのが良い出発点となります。
特定の問題が特定されると、プログラムのデバッグが行われ、修正が適用されます。修正が正しく機能することを確認するため、その基準に基づいてプログラムが再度テストされます。回帰テストによって、ある修正によってそのプログラムまたは他のインターフェースに別の問題が発生する可能性を低減できます。そのため、特定の修正によって他の何かに影響がないかどうかをテストするために、関連する一連のテストケースを繰り返す必要がある場合があります。このテストの実施方法については、このセクションで詳しく説明します。
回帰テストケースを選択する際には、さまざまなテストレベルを考慮してください。単体テスト、結合テスト、システムテストのケースが適しています。修正内容と直接関係のあるケースを選択するとともに、基本的なビジネスシナリオが引き続き機能することを証明できる、ビジネス上重要なケースもいくつか含めてください。また、非機能テスト（セキュリティ、パフォーマンス、ユーザビリティ）が、ビジネス継続性を証明する上で重要な役割を果たすことも忘れないでください。
企業によっては、あるユニットに不具合が修正されると、そのユニットに関するすべての単体テストケースが再実行される場合がある。
要件リストから、機能が類似している関連領域を特定できます。これらの領域がテストグループとなります。例えば、鉄道予約システムでは、チケット予約に関連するものはすべて機能グループであり、レポート生成に関連するものも機能グループです。同様に、機能面に基づいてテストグループを特定する必要があります。
テストケースにおいては、優先順位を明確にする必要があります。ソフトウェアプロジェクトのテストにおいては、特定のテストケースが最も重要視され、それらが失敗した場合は製品をリリースできません。一方、機能的に重要度の低いテストケースや、外観上の問題に過ぎないテストケースもあり、それらが失敗しても機能に大きな支障をきたすことなく製品をリリースできます。これらの優先順位は明確に定める必要があります。また、テストグループにも割り当てることができます。
テストケースを実行する際、テストリーダーとプロジェクトマネージャーは、テスト活動に関してプロジェクトがどの段階にあるかを正確に把握する必要があります。プロジェクトの進捗状況を把握するためには、個々のテスターからの情報がテストリーダーに届く必要があります。これには、実行されたテストケース、所要時間、合格したテストケースの数、失敗したテストケースの数、実行できなかったテストケースの数などが含まれます。また、プロジェクトがどのくらいの頻度でステータスを収集しているかも明確にする必要があります。プロジェクトによっては、ステータスを毎日または毎週収集する慣習がある場合もあります。
テストケースを実行する際には、実行日時、実行者、所要時間、結果などの実行詳細を記録しておくことが重要です。これらのデータは、テストリーダー、プロジェクトマネージャー、およびすべてのチームメンバーが中央の場所にアクセスできる必要があります。中央サーバーの特定のディレクトリに保存するのが適切であり、ドキュメントには保存場所とディレクトリについて明確に記載する必要があります。ドキュメントとファイルの命名規則についても明記する必要があります。
理想的には、ソフトウェアは一連の要件を完全に満たす必要があります。設計段階から、ソフトウェア開発プロセスにおけるすべてのドキュメントで、各要件に対応する必要があります。ドキュメントには、HLD、LLD、ソースコード、単体テストケース、統合テストケース、システムテストケースが含まれます。要件トレーサビリティマトリックスでは、行に要件が、列に各ドキュメントが示されます。ドキュメントが特定の要件に対応し、そのドキュメント内の要件IDに関連する情報が記載されている場合、交差するセルに印が付けられます。理想的には、すべての要件がすべてのドキュメントで対応され、すべてのセルに有効なセクションIDまたは名前が入力されていれば、すべての要件が対応されていることがわかります。いずれかのセルが空の場合は、要件が正しく対応されていないことを意味します。
経営陣は、テストサマリーを週単位または月単位で入手したいと考えるかもしれません。プロジェクトが非常に重要な場合は、日単位での入手が必要になる場合もあります。このセクションでは、経営陣向けにどのような種類のテストサマリーレポートを作成するのか、またその頻度を明確にする必要があります。
テスト戦略は、プロジェクト全体を通してテストチームが何を行うのかを明確に示すものでなければなりません。必要に応じて、この文書をクライアントに提示することも可能です。この文書を作成する担当者は、製品領域に関する豊富な知識と経験を持つ、高度な専門性を備えた人物でなければなりません。なぜなら、この文書がテスト活動におけるチーム全体の指針となるからです。テスト戦略は、プロジェクト開始時にテストチームのメンバーに明確に説明する必要があります。