Test Closure – Software Testing Life Cycle – Manual Testing Training
Test Closure – Software Testing Life Cycle – Manual Testing Training
V. Test Closure :
After completion of all test cycles and all major bugs closing( Remaining bugs are deferred due to low severity and low priority), PO and SM can site with testers to confirm testing was enough in current sprint before release to customer. In this test closure meeting PO and SM can analyse bellow factors:
Coverage analysis:
1. All modules tested (example login, MT , MS)
2. All reasonable tests conducted ( Ex: FT,UT,CT,HCT,PT)
Sprint stability:
80 – 20 Rule
% of testing | % of bugs |
20%
80% |
80%
20% |
Analysis of deferred bugs:
Deferred bugs are postponable or not?
After completion of test closure review meeting, testers can concentrate on final regression testing or post-mortem testing or pre-acceptance testing by following below process.
After completion of final regression testing, testers can concentrate on traceability matrix preparation in ms-excel or open office excel by following IEEE 829 rules.
User Story | Test Scenario ID | Test Result | DR ID | Closed or Deferred | Comments | |||||||||||||||
Login |
|
|
|
|
|
The above like traceability matrix is also called as test summary report.
Case study 1 ( Documents in Agile Scrum related to development and Testing):
Document | Prepared by | Using | Standard |
Product Backlog | PO | MS-Excel or Open office Excel | IEEE 830 |
Sprint Backlog | PO & SM | MS-Excel or Open office Excel | IEEE 830 |
Unit Test Scenarios and Cases | Developers | MS-Excel or Open office Excel | IEEE 830 |
Integration test scenarios and cases | Developers | MS-Excel or Open office Excel | IEEE 830 |
Sprint test Strategy | PO | Ms- word or open office word | IEEE 829 |
Sprint test plan | SM | Ms- word or open office word | IEEE 829 |
Sprint test scenarios and cases and data | Testers | Ms-Excel or Open office Excel | IEEE 829 |
Defect Report | Testers | Ms-Excel or Open office Excel and Ms- outlook or lotus notes | IEEE 829 |
Traceability matrix | SM and Testers | Ms-Excel or Open office Excel | IEEE 829 |
Case study 2 (Testing Principles):
1) Exhaustive testing impossible.
2) 100% bug free software is not possible (because some bugs are deferred due to low severity and low priority)
3) Early testing, means introduce developers and testers in a project on same day.
Example:
4) Pesticide paradox, means review test scenarios, cases and data repeatedly.
5) Defects clustering, means grouping defects to improve scales of developers for upcoming sprints.
Case study 3: Ad-hoc testing:
From testing principles exhaustive testing is impossible and Ad-hoc testing is not responsible. So most of the companies can follow optimal testing. In rare cases few companies can follow Ad-hoc testing in different ways due to risks.
1) Monkey testing or Champagne testing:
Due to lack of time, some testers can test main modules of the sprint instead of all modules.
2) Gorilla rides testing:
Due to lack of time, some testers can test some modules randomly instead off all modules.
3) Buddy testing:
Due to lack of time, developers and testers can continue development and testing parallely.
4) Exploratory testing:
Due to lack of documentation, testers can depend on past experience, discussions with customer, discussions with developers, internet browsing and operating similar software’s to understand project and test project.
5) Pair testing:
Due to lack of skills junior testers can join with senior testers to share their knowledge during testing.
6) Be bugging testing:
To improve skills of testers developers can release a sprint with known bugs.
In this article we have seen Test Closure – Software Testing Life Cycle – Manual Testing Training . This completes Manual Testing in brief and in easy way to understand. In the next article on wards we will see Selenium Automation Testing.