Test Plan Detailed
Test Plan
1. Introduction
1.1 Overview of System
1.2 Purpose of this Document
1.3 Audience
2. Scope of the Testing and Test Strategy
2.1 Scope of the Testing
2.2 Test Strategy
3. Test Process
4. Test Approach
4.1 Full Test Cycle
4.1.1 Build Verification Test (Smoke Test)
4.1.2 Defect Verification
4.1.3 Functional Test Pass
4.1.4 Performance & Stability Test
4.1.5 Regression Test
4.2 Daily Builds
4.2.1 Basic Test
4.2.2 Basic Performance Test
5. Test Criteria
5.1 Test Entry Criteria
- Release note has been issued
- Release note stating the builds information, build deployment information, Defects that have been fixed, open issues
- Builds are available on staging
- Unit test and integration test results are attached
- Test Environment is completely ready
- Req Specification is available in case any changes
5.2 Test Exit Criteria
- Certification by the QA that all Severity 1 and Severity 2 problems have been fixed
- Complete of the execution of all test cases and scenarios for this project.
- Sign-off on all QA documentation including the Load form.
- System Interfaces function according to Requirements and Design
- Performance/Load/Stress Requirements are met and function within acceptable levels (where applicable)
5.3 Test Stop Criteria
- Any critical defect or Show Stopper that prevents the QA from proceeding with any further test execution. The testing would be stopped till such issues have been resolved.
6. Error Management
6.1 Bug Lifecycle
6.2 Bug Classification
- Bugs can be classified according to the Severity and Priority which is mentioned as below
Severity 1: All the showstopper Bugs should come under this category. I.e. if, because of a consistent crash during processing of a particular type of application, testing cannot be done further cab be categorize as a showstopper.
Severity 2: All the System Errors and Functional Errors fall under this category. I.e. Report showing wrong data, not satisfying the logic and any drilldown not working.
Severity 3: The errors, which can be ignored for the time being and can be overcome by using the work around and which don’t affect the system functionality directly.
Severity 4: All the cosmetic errors fall under this category i.e. spelling mistakes and incorrect Bookmark name etc.
Priority 1: Immediate fix, blocks further testing, Very visible.
Priority 2: Must be fix before the product is released.
Priority 3: Should be fixed if time permits.
Priority 4: Would be fixed but can be released as it is.
7. Configuration Management
7.1 Data Stage Job Testing in Production
7.2 Front End Report Testing in Production
8. Risks and Assumptions
8.1 Risks Associated with the System Testing
- Hardware Dependency
- Data availability Issue
- Wrong data from Client
- Not Fixation of Bugs in time
- Staffing Issue
- DB Issues
8.2 Assumption
- Functional and technical specifications will be signed off by the business.
- Software will be released in the appropriate environment in time.
- Software is of the required quality i.e. the code should be appropriately tested before releasing to the next environment.
- All "Show-Stopper" bugs receive immediate attention from the development team.
- All bugs found in a version of the software will be fixed and unit tested by the development team before the next version is released.
- The required hardware/software/test environment will be available in time.
9. Test Environment
- E2E Test Environment
- Software Configuration
10. Test Schedule
11. Deliverables
12. Signoff
1. Introduction
1.1 Overview of System
1.2 Purpose of this Document
1.3 Audience
2. Scope of the Testing and Test Strategy
2.1 Scope of the Testing
2.2 Test Strategy
3. Test Process
4. Test Approach
4.1 Full Test Cycle
4.1.1 Build Verification Test (Smoke Test)
4.1.2 Defect Verification
4.1.3 Functional Test Pass
4.1.4 Performance & Stability Test
4.1.5 Regression Test
4.2 Daily Builds
4.2.1 Basic Test
4.2.2 Basic Performance Test
5. Test Criteria
5.1 Test Entry Criteria
- Release note has been issued
- Release note stating the builds information, build deployment information, Defects that have been fixed, open issues
- Builds are available on staging
- Unit test and integration test results are attached
- Test Environment is completely ready
- Req Specification is available in case any changes
5.2 Test Exit Criteria
- Certification by the QA that all Severity 1 and Severity 2 problems have been fixed
- Complete of the execution of all test cases and scenarios for this project.
- Sign-off on all QA documentation including the Load form.
- System Interfaces function according to Requirements and Design
- Performance/Load/Stress Requirements are met and function within acceptable levels (where applicable)
5.3 Test Stop Criteria
- Any critical defect or Show Stopper that prevents the QA from proceeding with any further test execution. The testing would be stopped till such issues have been resolved.
6. Error Management
6.1 Bug Lifecycle
6.2 Bug Classification
- Bugs can be classified according to the Severity and Priority which is mentioned as below
Severity 1: All the showstopper Bugs should come under this category. I.e. if, because of a consistent crash during processing of a particular type of application, testing cannot be done further cab be categorize as a showstopper.
Severity 2: All the System Errors and Functional Errors fall under this category. I.e. Report showing wrong data, not satisfying the logic and any drilldown not working.
Severity 3: The errors, which can be ignored for the time being and can be overcome by using the work around and which don’t affect the system functionality directly.
Severity 4: All the cosmetic errors fall under this category i.e. spelling mistakes and incorrect Bookmark name etc.
Priority 1: Immediate fix, blocks further testing, Very visible.
Priority 2: Must be fix before the product is released.
Priority 3: Should be fixed if time permits.
Priority 4: Would be fixed but can be released as it is.
7. Configuration Management
7.1 Data Stage Job Testing in Production
7.2 Front End Report Testing in Production
8. Risks and Assumptions
8.1 Risks Associated with the System Testing
- Hardware Dependency
- Data availability Issue
- Wrong data from Client
- Not Fixation of Bugs in time
- Staffing Issue
- DB Issues
8.2 Assumption
- Functional and technical specifications will be signed off by the business.
- Software will be released in the appropriate environment in time.
- Software is of the required quality i.e. the code should be appropriately tested before releasing to the next environment.
- All "Show-Stopper" bugs receive immediate attention from the development team.
- All bugs found in a version of the software will be fixed and unit tested by the development team before the next version is released.
- The required hardware/software/test environment will be available in time.
9. Test Environment
- E2E Test Environment
- Software Configuration
10. Test Schedule
11. Deliverables
12. Signoff
Comments
Post a Comment