Defining Test Scope and Test Basis
Test scope and test basis are two critical concepts that define the boundaries and source material for your testing effort. Getting these wrong is one of the most common root causes of testing projects that run over time, miss critical defects, or produce irrelevant test coverage.
Test Scope - What You're Testing
Test scope is the explicit boundary of your testing effort - what IS and what IS NOT included. Define scope by listing features in scope (by requirement ID and feature name), features out of scope (with explicit justification), environments to be tested (dev, staging, production smoke), devices and browsers to be tested, and data types and user roles covered. A common mistake: defining scope too broadly ('test all features') because it sounds thorough. Undefined scope means undefined completion - you can never be 'done' with vague scope. Explicit, bounded scope gives you a clear completion target and protects you when stakeholders ask why untested features (that were out of scope) have bugs.
Combine manual + automated testing for comprehensive coverage
Test Basis - Where Tests Come From
- Test basis is the documentation from which test cases are derived. Common test basis sources: Requirements Specification (SRS/FRS), User Stories with acceptance criteria, Use Case documents, Design prototypes and wireframes, API specifications and data dictionaries, Previous test cases and defect history (for regression), Business process documentation and workflow diagrams
- The test basis determines test coverage - if your test basis is incomplete (missing requirements), your test coverage will have gaps. If your test basis has errors (wrong requirements), your test cases will verify incorrect behavior
- Best practice: create a column in your RTM for 'Test Basis Reference' - for each test case, document which requirement, user story, or design element it traces to. This proves coverage and enables impact analysis when the test basis changes
Tip
Tip
Practice Defining Test Scope and Test Basis in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Defining Test Scope and Test Basis from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Defining Test Scope and Test Basis is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- Test scope and test basis are two critical concepts that define the boundaries and source material for your testing effort.
- Test basis is the documentation from which test cases are derived. Common test basis sources: Requirements Specification (SRS/FRS), User Stories with acceptance criteria, Use Case documents, Design prototypes and wireframes, API specifications and data dictionaries, Previous test cases and defect history (for regression), Business process documentation and workflow diagrams
- The test basis determines test coverage - if your test basis is incomplete (missing requirements), your test coverage will have gaps. If your test basis has errors (wrong requirements), your test cases will verify incorrect behavior
- Best practice: create a column in your RTM for 'Test Basis Reference' - for each test case, document which requirement, user story, or design element it traces to. This proves coverage and enables impact analysis when the test basis changes