After determining that test execution has been complete the data from completed test activities need to be collected and consolidated. You need to analyze the data to find out facts and numbers about the testing activities during project cycle.
Test closure activities are done mostly after the product is delivered but there are other instances as well where test closure is done like, if project got cancelled or after maintenance release is done. Test closure activities mainly comprise of four types:
Ensure Test Completion
Making sure that all the testing work has actually been completed and concluded. In complex projects it is very likely that their are few things missed so the test manager needs to double check the test plan and make sure that all the planned activities are actually done. They need to make sure that all the planned test cases are either executed or skipped after stakeholders approval. Also all the defects in the project should either be fixed and re-tested or deferred or accepted as permanent restrictions [For example- Technology limitations].
Handover Test Artifacts
Deliver the test artifacts to people who need it in future. After the release of the software, there are other people who will still be working on the project to support it, for example maintenance and support team. These teams will need the test artifacts to figure out if the reported issues are already known defects or its a new issue in production. Test artifacts are also needed by maintenance team to figure out the steps to execute the different test scenarios or regression after any fixes are done by maintenance developers.
Project Retrospectives
This is very important activity of test closure, project retrospectives are done to document the lessons learned in the project(both good and bad). In these meetings it is discussed that we continue to use best practices that worked really well during project and stop using any bad practices. There are many important areas about project that need to be discussed in retrospective meetings, some of those areas are:
- Did we did right test estimation or estimation done for project was misjudged. If we found that lot of defects got missed in testing then we need to ask question, was it due to lack of test team skillset or it was actually due to incorrect test estimates which didn’t allow any time for exploratory testing?
- Did we include the right stakeholders in quality risk analysis. If we found large defect cluster in some integrated component very late during integration testing phase then the broader representation (Including people from other integration component teams) in quality risk analysis would have avoided those integration defects.
- Is the process followed in current project efficient or there are improvements required in the process as well.
- Did the testing go as planned or there were variances from the plan which needs to be rectified in future projects.
- What is the trend of defects found in project. For example, were the defects mostly found late because we skipped a test level which would have identified defects in advanced and a much lower cost. We also need to find out was there any lack of skillset in team due to which team was not able to find issues or it was a new technology due to which large number of issues were found.
Archive Test Work Products
Finally, all the test work products like test results, test logs, test status reports, test cases, test plans etc. should be stored in configuration management system. The test plan and project plan should be stored in planning archive and have a clear linkage to system and version they were used on, similarly the test execution reports should clearly be linked to the version of product for which they were created.
