TM-2.3.5 (K2)テストの選択、テストの優先度付け、および工数の割り当てに関するさまざまなオプションの例を示す。

テストを選択するためのリスクベースドテスト以外の技法は以下のようなものがある。

要件ベースドテスト

曖昧性レビュー、テスト条件分析、原因結果グラフなどのいくつかの技法を活用できる。
要件ベースドテストに対する一般的な障害は、多くの場合、要求仕様が曖昧、検証不能、不完全、または存在しないことである。

曖昧性レビュー
一般的な要件の欠陥チェックリストを使用することにより、要件の曖昧性を識別し除去する。

テスト条件分析
要求仕様を詳細に読み、カバーするテスト条件を識別する作業を行う。
要件に優先度が割り当てられている場合は、優先度を使用して工数を割り当て、テストケースに優先度付けすることができる。

原因結果グラフ
非常に大きなテストの問題をマネジメント可能な数のテストケースに減らし、テストベースの機能を100%カバーできるという広範な用途がある。
また、テストケースの設計時にテストベースのギャップを識別することで、ドラフトの要件に基づいてテスト設計を開始した際に、ソフトウェア開発ライフサイクルの早期に欠陥を識別できる。

原因結果グラフの採用における主な障害の1つは、グラフ作成が複雑なことである。
手動で作成すると複雑になるので、それを支援するツールが用意されている。

モデルベースアプローチ

要件を拡張するために、既存の要件を使用することに加え、システムの実際の使用状況を正確に描けるように、ユースケース、ユーザ 、入力、および出力を組み合わせて利用方法または運用プロファイルを作成するアプローチもある。

特徴
機能だけではなく、使用性、相互運用性、信頼性、セキュリティ、および性能もテスト可能。

注意
リスクベースドテストと同様に、利用方法プロファイルも最終的な実際の結果を完全にはモデル化できない可能性がある。

方法論的アプローチ

チェックリストなどの方法論的アプローチもある。
非常に安定したプロダクトの場合は、テストする主な機能領域と非機能領域のチェックリストと、既存のテストケースのリポジトリとを組み合わせることで十分な可能性がある。
ただし、チェックリストは通常、発生した変更の種類と量に基づいて、工数の割り当てとテストの順序付けに関する経験則が必要となるため、ごくわずかな変更以外のテストで使用される場合、 有効性が低下する傾向がある。

対処的アプローチ

テスト実行の前には、テストの分析作業、設計作業、または実装作業をほとんど行わない対処的アプローチもある。

特徴
テストチームは、実際に提供されたプロダクトに対する対応に焦点を当て、バグの偏在を検出すると、そこでさらなるテストを実施する。
また、優先度付けと割り当ては、完全に動的に行う。

注意
対処的アプローチは他のアプローチの補完として機能するが、 単独で採用した場合は、重要ではあるが少数のバグしか発生していないアプリケーションの主要な領域を見逃す傾向がある。

テストプロセスにおけるテストの優先度付けと工数の割り当て

シーケンシャルライフサイクル
要件フェーズでテストの選択とテスト工数の割り当てを行い、最初にテストの優先度付けを行う。

イテレーティブライフサイクルまたはアジャイルライフサイクル
イテレーションごとにテストの選択、優先度付け、および工数の割り当てが必要になる。

テストの計画作業とコントロール
リスク、要件、および利用方法プロファイルが増大する程度を考慮し、それに対応する必要がある。

テストの分析、設計、および実装
テスト計画作業で決定された割り当てと優先度付けが適用されるべきである。

テスト実行
テスト計画作業で決定した優先度に従ってテストを実行するべきである。
ただし、計画を作成した後で得られた情報に基づいて、定期的に優先度付けを更新することも重要である。

テスト結果と終了基準の評価とレポート
[評価・レポートするもの]
* リスク
* 要件
* 利用方法プロファイル
* チェックリスト
* 上記以外のガイド

必要に応じて、テストの優先度付け方式に基づいて、 テストのトリアージ(実行順序判定)を行う必要がある。

テストレポートでは、実現された利点と実現されていない利点の他、対応済みのリスクと未対応のリスクを掲載する必要がある。

テストの完了度合いの測定
結果レポートおよび終了基準評価の一環として、テストマネージャはどの程度テストが完了しているかを測定できる。
この測定では、テストケースと検出した欠陥が関連するテストベースにまで遡って追跡する。

テストステークホルダのニーズと期待に関連するメトリクスと成功のための基準を評価する
これには品質に関する顧客およびユーザのニーズと期待を含む。
テストがこれらのニーズと期待を満たした場合のみ、テストチームが本当に有効に機能したと言える。

問題