Test coverage matrix (TCM):Contains the details of component to be tested with brief description ,total no of test cases ,no of test cases executed, no of test cases passed, no of test cases failed, no of test cases not executed and alsoCurrent Test Coverage: (Total Number Executed) / (Total Number of Tests) * 100Test Case Success Rate: (Total Number Passed) / (Total Number Executed) * 100 And in the TCM summary we give the following details build wise:Build no:Total no of test cases failed:Total no of test cases not executedTotal no of test cases/scriptsComponent ID -Total no of test cases failed-Reason for fail-Total no of test cases not executed-Reason for not executing

Traceability Matrix

“In a software development life cycle, requirements are translated into specifications based on which code is developed. Once the construction process is complete, the product is put through various stages of testing before it finally goes live.

Requirement: A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.

Specification: A declarative description of what something is or does.

Traceability is the common thread that ensures that the verification and validation of the product is complete.  Requirements tracing is the process of documenting the links between the user requirements for the system you’re building and the work products developed to implement and verify those requirements.  These work products include software requirements, design specifications, software code, test plans and other artifacts of the systems development process.  Requirements tracing helps the project team to understand which parts of the design and code implement the user’s requirements, and which tests are necessary to verify that the user’s requirements have been implemented correctly.  Table 1 illustrates the concept of a trace matrix.

Table1

Requirement Functional Specification

Design Specification

Code section Test Condition Defect ID

1 1.1 3.1Line

300-350

12

13

14

D2

-

D6

1.2 3.2Line

450-600

21

22

23

-

-

-

Table1: Assumes that the trace matrix includes development activities as well. However, this is not always possible as data may not be readily available. In the above example, Requirement Number 1 has resulted in two defects (D2 and D6). These can be traced back to Conditions 12 and 14 respectively.  By drilling down further, it is possible to identify the impacted specifications and the relevant code section.  Where the trace excludes construction activity, the trace matrix should include other elements of the test suite as given in Table 2.

Table2:

Requirement Functional Specification

Test Condition

Test Case Test Script Defect ID

1 1.112

13

14

12.1/12.2

13.1/13.2/13.3

14.1

T5

T6

T6

D2

-

D6

1.221

22

23

21.1

22.1/22.2

23.1/23.2/23.3

T8

T8

T8

-

-

-

 Table 2: Drills further into the actual test case that failed. This gives additional information to the developer to be able to zoom into the cause of the defect as well as assist the users in assigning a severity classification to the defect. For example, the defect may not relate to a critical functionality or the user could be trained to avoid the defect. These decisions become imperative when the time to fix is high and the go-live date is non negotiable.

 

.