テストの範囲を定義することは、手動テストにおける基本的な課題であり、アプリケーションの最も重要でクリティカルな部分に焦点を合わせることを可能にします。
プロジェクトが進展するにつれて、テスト可能な機能の量が増加し、すべてのシナリオを手動でカバーすることは不可能になっています。アジャイル/インクリメンタル開発の出現により、scopeの定義の役割が大幅に増加しました。
テストの範囲があいまいである場合、リスクが生じます：
テストの範囲は、以下に基づいて定義されるべきです：
重要な特徴：
実装されたすべてのもの、特に最小の詳細まで必ずテストする必要がありますか？
いいえ、テストの原則は、特にエラーが最も発生しやすく、バグがビジネスに大きな影響を与える場所に焦点を当てることです。
テスターは、新しい要件が出た場合に合意なしで独自に範囲を広げたり狭めたりできますか？
いいえ、範囲の変更は、ギャップや作業の重複を避けるためにプロダクトマネージャーやチームリーダーと合意する必要があります。
範囲を定義する際に技術文書のみに依存することは十分ですか？
いいえ、ビジネスコンテキスト、実際のユーザーの課題、顧客からのフィードバックも考慮する必要があります。
テスターがすべての機能とケースをカバーすることを独自に決定し、その結果、クリティカルなパスのテストに時間が不足し、主要なバグが見逃されます。
プラス：
マイナス：
スプリントの開始時に、テスターが計画に参加し、チーム全体で範囲を固定し、最も重要なユーザーシナリオに焦点を当て、作業のボリュームを合意し、Confluenceに文書化します。
プラス：
マイナス：