1.3 テスト分析

TM-1.3.1 (K3)トレーサビリティを確保し、テスト目的、テスト戦略、およびテスト計画に基づいて定義されたテスト条件の完全性と一貫性をチェックする。

ただし、これらの活動は、テスト設計成果物の作成を推進するために、並列的、統合的、または反復的な活動として実装できることを認識する必要がある。

テスト条件は、テストベース、テスト目的、およびプロダクトリスクを分析することにより、識別可能である。

また、成功のための詳細な測定および対象(たとえば終了基準の一部)と見なすことも可能であり、成功のためのテスト目的、および他のプロジェクト またはステークホルダの基準を含む、テストベースおよび定義された戦略目的にまで遡ることができる必要があ る。

さらに、テスト条件は、テスト設計およびそれ以外のテスト成果物を作成した際には、これらの成果物を追跡 できる必要もある。

特定のテストレベルのテスト分析は、そのレベルのテストベースが確立されれば、すぐに実行可能である。

公式 なテスト技法およびそれ以外の一般的な分析技法(たとえば分析的リスクベースド戦略や分析的要件ベースド 戦略など)を使用すると、テスト条件を識別できる。

テスト条件では、テストレベル、分析を行うときに使用できる 情報、および選択された詳細レベル(つまり、文書化の粒度)に応じて、値または変数を指定する場合もあれば、 そうでない場合もある。

テスト条件を指定するための詳細度合いを決定する際には、次のようなさまざまな要因を考慮する必要がある。

テストレベル

テストベースの詳細度と品質

システムまたはソフトウェアの複雑性

プロジェクトリスクとプロダクトリスク

テストベース、テスト内容、およびテスト方法間の関係

使用するソフトウェア開発ライフサイクル

使用するテストマネジメントツール

テスト設計およびその他のテスト成果物に関する、詳細度、および文書化のレベル

テストアナリストのスキルと知識

テストプロセスおよび組織自体の成熟度(成熟度が高いほど、高い詳細度合いが必要となることもあれば、低い詳細度合いが可能になることもあることに注意)

コンサルテーションのために他のプロジェクトステークホルダを利用できる可能性

詳細にテスト条件を指定すると、多数のテスト条件を作成する傾向がある。

たとえば、一般的な e コマースアプ リケーション用の 1 つのテスト条件「チェックアウトのテスト」があるが、詳細なテスト条件ドキュメントでは、この条 件は、サポートする各支払い方法に対してそれぞれ 1 つの条件があり、対象の各宛先国に対してそれぞれ 1 つの条件があるなど、複数のテスト条件に分かれる場合がある。

詳細にテスト条件を指定する場合の利点には、次のようなものがある。

他のテスト成果物(たとえばテストケースなど)を、より柔軟にテストベースおよびテスト目的に関連付けできる。

これにより、テストマネージャはより適切で詳細なモニタリングおよびコントロールが可能となる。

Foundation Level で説明したように、テストベースが確立されてすぐに、さらに可能であればシステム アーキテクチャと詳細設計が使用可能となる前に、より上位のテストレベルのためにプロジェクトの早期に実行することで、欠陥の防止に貢献する。

テスト成果物を、ステークホルダが理解できる用語で説明できる(多くの場合、テストケースおよびそれ以外のテスト成果物は、ビジネスステークホルダにとって何も意味せず、実行されたテストケースの数などの単純なメトリクスは、ステークホルダのカバレッジ要件に対して無意味である)。

他のテスト活動だけではなく、他の開発活動にも影響を与え、活動を導くのに役立つ。

テストの設計、実装、および実行において、詳細な測定と対象をより効率よく網羅し、より最適化した成果物を生成する。

あるテストレベルにおける、より明確な水平トレーサビリティのためのベースを提供する。

詳細にテスト条件を指定する場合の短所には、次のようなものがある。

時間がかかる場合がある。

環境が変わった場合、保守性を維持するのが困難になる場合がある。

チーム全体で、形式化のレベルを定義し実装する必要がある。

次の状況では、詳細なテスト条件の仕様が、特に効果的な可能性がある。

開発ライフサイクル、コストや時間の制約、またはその他の要因に対応するために、チェックリストなどの簡易なテスト設計文書化方式を使用している。

公式な要件、またはそれ以外の開発成果物が、テストベースとして、ほとんど、あるいはまったく使用できない。

プロジェクトが大規模、複雑、または高リスクであり、単純にテストケースを開発成果物に関連付けることでは提供できないモニタリングおよびコントロールのレベルを必要としている。

テストベースを容易に、直接テスト設計成果物に関連付けできる場合、低い詳細度でテスト条件が指定可能で ある。次のケースでは、その可能性がより高くなる。

コンポーネントレベルのテスト

テスト内容とテスト方法との間に単純な階層関係が存在する、複雑性の低いプロジェクト

テストを定義するためにユースケースを活用できる受け入れテスト