© 2007, Cognizant Technology Solutions. All Rights Reserved.The information contained herein is subject to change without notice. C3: Protected

Fundamentals of Test Closure

Session 1: Test Closure – An Overview

2

About the Author

Created By: Saravanan Solai (226481); Mathuram (105686)

Credential Information:

Saravanan holds a B.TECH – Information Technology with 5+ years of Software Testing experienceMathuram has over 11 years of experience and is a PMP, CMST certified professional

Version and Date:

FOTC/PPT/0311/1.0

© 2007, Cognizant Technology Solutions. All Rights Reserved.The information contained herein is subject to change without notice.

Test Closure

4

Test Closure – An Introduction

Test Closure involves the following activities:

1. Preparation of Test Summary Report

2. Preparation of Application Stability Report

3. Retrospection of the Testing activities that are planned and executed● Schedule adherence and

deviation● Root cause Analysis● Risks encountered and

Mitigation strategies followed● Document Best Practices

created and followed● Document critical issues

encountered and lessons learnt

Fig: Test Closure Process

Retrospection • Schedule adherence and deviation• Root cause Analysis• Risks encountered and mitigation strategies followed• Document Best Practices created and followed• Document critical issues encountered and lessons learnt

Preparation of Test Summary Report

Te

st C

losu

rePreparation of Application Stability Report

5

Test Closure is a formal activity to check the adherence to the Test Plan

It is performed at the end of all testing activities that are in the scope for every release of a project

Test Closure – An Overview

6

Test closure is needed for the following activities:» To validate if all the agreed activities within the scope of

testing are completed successfully as per the Test Plan» To arrive at the Go/No-Go decision on the application to

move the production based on the inferences from the testing

» To retrospect and understand the following in the testing strategy and process followed

● What went well?● What could have been done better to make the

application or testing process effective?● Factors that contributed for the variances● Best practices created or adopted – the effectiveness

of using those best practices in the project● Lessons learnt and how this knowledge can be used to

do better in future releases

Need for Test Closure

7

» To measure and analyze the variances - Planned versus Actual (Effort, Schedule, Cost and Quality) in accordance with Test Plan and Project plan

» The inferences from the retrospection can be utilized to improve the process and execution during future releases

Need for Test Closure (Contd.)

8

Test Closure

9

Test Closure - Activities and Deliverables

Activities Deliverables

Prepare Test Summary Report Test Summary Report

Prepare Application/Product Stability Report AQI / PQI Report

Retrospection Critical Issues ListLessons Learnt Document

Following are the list of activities and their respective deliverables:

© 2007, Cognizant Technology Solutions. All Rights Reserved.The information contained herein is subject to change without notice.

Test Summary Report

11

A Test Summary Report summarizes the following:» Various activities carried out during the testing of an

application and the outcome» Scope of testing (items that are tested and not tested)» Inference of the stability of the application from testing» Summary of all the test results of the project» Brief summary of Metrics that are generated» Details of known issues in the application and

recommendations» Risks of moving the application to the next phase of testing

or production» Reference to the Placeholders of the Test Deliverables

Test Summary Report is shared with all the stakeholders of the project

What is Test Summary Report?

12

Preparation of a Test Summary Report requires the following inputs:» Approved template of Test Summary Report» Approved Test Plan» Required information of the testing activities* like

● Scope of testing (Items to be tested and Not tested)● Number of Test cases prepared● Number of test cases executed● Number of test cases passed● Number of test cases failed● List of defects and summary of defects by

− Status− Severity− Priority− Module− Trend of defects

* - If there are multiple rounds / types of testing these information needs to be captured for each of them

Inputs Required to Prepare a Test Summary Report

13

» Delivery Metrics details» List of known issues in the application and their

implications» Risks in moving the application to the next stage of

testing or production

Inputs Required to Prepare a Test Summary Report (Contd.)

Test Summary Report_Sample

© 2007, Cognizant Technology Solutions. All Rights Reserved.The information contained herein is subject to change without notice.

Application Stability Report

15

Application Stability Report is a report prepared after quantitative assessment of the stability of the application governed by various factors like» Test coverage » Test case success » Outstanding defects

Each factor is assigned a weightage to arrive at the stability index

GO / No-Go decision is made based on the system stability

The stake holders of the project may decide whether to move the application to the next phase of testing or production based on the details in this report

Application Stability Report

Application Stability Report_Sample

© 2007, Cognizant Technology Solutions. All Rights Reserved.The information contained herein is subject to change without notice.

Issues Encountered and Lessons Learnt

17

During Test Closure, the issues that were encountered by the testing team are identified and discussed

The negative impact of those issues and the resolutions followed for those critical issues are documented

Unresolved outstanding issues are listed out The resolutions that were effective can be taken as

lessons learnt while planning for future releases

Critical Issues Encountered

Sample Critical Issues List

Sample Lessons Learnt

© 2007, Cognizant Technology Solutions. All Rights Reserved.The information contained herein is subject to change without notice.

Defect Causal Analysis

19

Defects (application and review) that are missed to have identified in one phase and are identified in later phases are listed

These defects may have a negative impact on the project

The root causes for the leakage of these defects from one phase to another are identified using the following techniques:» Fishbone diagram» Pareto chart

Once the causes are identified, these are taken as inputs for the defect prevention plan during the next release

Defect Causal Analysis

© 2007, Cognizant Technology Solutions. All Rights Reserved.The information contained herein is subject to change without notice.

Project Closure