システムテストフェーズに入る前の工程、つまり開発や単体、結合テストが遅延することはよくあることです。
その結果、システムテストフェーズにしわ寄せがゆき、大きなプレッシャーの中でテストを実施しなければなりません。
しかし、テストをすること自体をやめたり、遅らせたり、ましてや手抜きテストなどできません。
実際のプロジェクトでは限られたリソースの中で最良のテストを実施するために、テストすべき対象を優先順位付けします。
「システムのどこが最も注意しなければいけない部分ですか？」
答えは1つではありません、どの部分をテストするかという優先順位付けはリスクベースでなければなりません。
テストにどれだけリソースをかけられるかとテスト後に欠陥が発見された場合のコストとの間には関係がります。
リスクによっては段階的な本番リリースする場合もあります。
段階的リリースでの一般的なテストアプローチは、リリースできそうな重要な機能をテストし、他の機能は後回しにすることです。
システムレベルのテストでは、まず第一に、製品やプロジェクトにおいて最も重要な領域をテストする必要があります。
最も重要な場所を特定するには、機能の表示領域や使用頻度、および故障した場合に想定される損失を鑑みて判断できます。
第二に、多くの欠陥を見つけられる場所をテストしなければいけません。
これは、製品内で欠陥のある領域を特定できれば判断できるでしょう。
プロジェクトの履歴から、欠陥のある領域を判断する何らかの手がかりを見つけられるでしょう。
製品の変更履歴からは、それ以上の手がかりを得られます。
プロジェクトの履歴、製品の変更履歴の両方を駆使して、テストに注力すべき領域とテストを省いてもよい領域等の優先順位リストを作ります。
テスト実行中に、いくつか欠陥が見つかった場合、その欠陥を分析することで、さらにテストを集中させるべき領域や、テストの方法を調整できます。
その理由は、欠陥が発生しやすい領域では欠陥が偏在しており、欠陥は開発者が作り出した特定の問題が症状となって顕在化しているからです。
そのため、欠陥の近くに欠陥が集まり、同じような種類の欠陥が多くなる傾向があります。
したがって、テスト実行フェーズの後半部分では、欠陥が発見された領域に焦点を当て、前に検出された欠陥と同様の種類を検出するためのテストを実施する必要があります。