Test Closure Activities

Test Closure Activities

Once test execution is determined to be complete, the key outputs are captured and either passed to the relevant person or archived. Collectively, these are test closure activities. Test closure activities fall into four main groups:

 

  1. Test completion check – ensuring that all test work is indeed concluded. For example, all planned tests are either run or deliberately skipped, and all known defects are either fixed and confirmation tested, deferred for a future release, or accepted as permanent restrictions.
  2. Test artifacts handover – delivering valuable work products to those who need them. For example, known defects deferred or accepted are communicated to those who will use and support the use of the system. Tests and test environments are given to those responsible for maintenance testing. Regression test sets (either automated or manual) are documented and delivered to the maintenance team.
  3. Lessons learned – performing or participating in retrospective meetings where important lessons (both from within the test project and across the whole software development lifecycle) are documented. In these meetings, plans are established to ensure that good practices are repeated and poor practices are either not repeated or, where issues cannot be resolved, they are accommodated within project plans. Areas to be considered include the following:
    1. Was the user representation in the quality risk analysis sessions a broad enough cross-section? For example, due to late discovery of unanticipated defect clusters, the team might have discovered that a broader cross-section of user representatives is participating in quality risk analysis sessions on future projects.
    2. Were the estimates accurate? For example, estimates may have been significantly misjudged and therefore future estimation activities need to account for this together with the underlying reasons, e.g., was testing inefficient or was the estimate actually lower than it should have been.
    3. What are the trends and the results of cause and effect analysis of the defects? For example, assess if late change requests affected the quality of the analysis and development, look for trends that indicate bad practices, e.g., skipping a test level which would have found defects earlier and in a more cost-effective manner, for perceived savings of time. Check if defect trends could be related to areas such as new technologies, staffing changes, or the lack of skills.
    4. Are there potential process improvement opportunities?
    5. Were there any unanticipated variances from the plan that should be accommodated in future planning?
  4. Archiving results, logs, reports, and other documents and work products in the configuration management system. For example, the test plan and project plan are both to be stored in a planning archive, with a clear linkage to the system and version they were used on.

These tasks are important, often missed, and we explicitly include them as part of the test plan.
It is common for one or more of these tasks to be omitted, usually due to premature reassignment or dismissal of project team members, resource or schedule pressures on subsequent projects, or team burnout. On projects carried out under contract, such as custom development, the contract should specify the tasks required.