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 also
Current Test Coverage: (Total Number Executed) / (Total Number of Tests) * 100
Test 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 executed
Total no of test cases/scripts
Component 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 Design Code section Test Condition Defect

Specification Specification ID
1 1.1 3.1 Line 12 D2

300-350 13 -

14 D6

1.2 3.2 Line 21 -

450-600 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 Test Test Case Test Script Defect ID

Specification Condition
1 1.1 12 12.1/12.2 T5 D2

13 13.1/13.2/13.3 T6 -

14 14.1 T6 D6

1.2 21 21.1 T8 -

22 22.1/22.2 T8 -

23 23.1/23.2/23.3 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.