Traceability Matrix

Traceability Matrix How to Create and Use ItTodays session is about an important QC tool, that is either over-simplified (read overlooked) or over-emphasized Traceability Matrix(TM).Most often, the making, reviewing or sharing of aTraceability Matrix is not one of the primaryQA processdeliverables so it is not majorly concentrated on, thus causing the under-emphasis. On the contrary, some clients expect a TM to reveal earth-shattering facets about their product (under test) and are disappointed.When used right, a Traceability Matrix can be your GPS for your QA journey.As is a general practice atSTH, we will see the What and How aspects about a TM in this article.What is a Traceability Matrix?The focus of any testing engagement is and should be maximum test coverage. By coverage, it simply means that we need to test everything there is to be tested. The aim of any testing project should be 100% test coverage.Requirements Traceability Matrix to begin with, establishes a way to make sure we place checks on the coverage aspect. It helps in creating a snap shot to identify coverage gaps.How to Create a Traceability Matrix?To being with we need to know exactly what is it that needs to be tracked or traced.Testers start writing theirtest scenarios/objectives and eventually the test cases based on some input documents Business requirements document,Functional Specifications documentand Technical design document (optional).Lets suppose, the following is our Business requirementsSample Business Requirement Document (BRD):

This is a site that aims at computerizing the loan system for XYZ bank. The following are the business targets that are to be achieved via this:

1. Loan process

The loan system must cater to both the existing and new users. For new users it should provide a way to apply for loan. The existing users should be able to access the loan information. The banker should be notified of the changes or new loan requests and can grant, reject, suggest changes to the request made

2. Ease of use

All the information should be easy to access. If the banker needs to make administrative changes, they should be able to do through the web interface.

3. Integration with the bank users list

The loan customers and the other bank customers list has to be merged but the identification of the loan customers should be unique.

The below is our Functional Specifications document (FSD) based on the interpretation of the Business requirements document (BRD) and the adaptation of it to computer applications. Ideally all the aspects of FSD need to be addressed in the BRD. But for simplicitys sake I have only used the points 1 and 2.

1 Loan Process

1.1 New users

The new users can access the bank URL and when they click on the Apply Loan button they are going to be displayed a page to enter their information.

The new user needs to provide first name, last name, address, DOB, SSN and email address mandatorily. The user can register or continue as a guest before entering the loan specific information. If the user chooses to continue as guest, there will not be a prompt for password selection. If the user chooses to register the user will be asked to choose a password.

1.2 Existing users

The existing users can be the ones who have applied for a loan and are waiting on confirmation or the ones that already have the loan granted. The users who are waiting will be displayed the information on in which stage the loan is at. The loan as soon as being applied is in the stage of Sent for review. Once it is reviewed it moves to Reviewed and approved or Reviewed and deleted based on the bankers decision.

2. Ease of use

2.1 All the information should be accessible in less than 3 clicks for a user.

Note: the BRD and FSD are not documented by QA teams. We are merely, the consumers of the documents along with the other projects teams.Based on the above two input documents, as the QA team we came up with the below list high-level scenarios for us to test.Test Scenarios from BRD and FSD:

Test scenario IDTest Objective/Test scenarios

TS_Loan_001Validate the "Apply Loan" feature as a new user

TS_Loan_002validate the "Apply Loan" feature as a already existing user

TS_Loan_003For a new user in the "Apply loan", check the guest customer option and apply loan

TS_Loan_004For a new user in the "Apply loan", check the Register option and apply loan

TS_Loan_005Login to the loan portal as an already a customer with a loan and check the information displayed

TS_Loan_006Check the Loan whose status is "Sent for review"

TS_Loan_007Check the Loan whose status is "Reviewed and approved"

TS_Loan_008Check the Loan whose status is "Reviewed and deleted"

TS_Loan_009Check for a visitor if the information on the site is accessible in less than 3 clicks or not

TS_Loan_010Check for a reigstered user if the information on the site is accessible in less than 3 clicks or not

TS_Loan_011Check for a banker if the information on the site is accessible in less than 3 clicks or not

Once we arrive here, now would be a good time to start creating the requirements traceability matrix.I personally prefer a very simple excel sheet with columns for each document that we wish to track. Since the business requirements and functional requirements are not numbered uniquely we are going to use the section numbers in the document to track. (You can choose to track based on line numbers or bulleted-point numbers etc. depending on what makes most sense for your case in particular.)Here is how a simple Traceability Matrix would look for our example:

The above document establishes a trace between, the BRD to FSD and eventually to the test scenarios. By creating a document like this, we can make sure every aspect of the initial requirements have been taken into consideration by the testing team for creating their test suites.You can leave it this way. However, in order to make it more readable, I prefer including the section names. This will enhance understanding when this document is shared with the client or any other teams. The outcome is as below:

Again, the choice to use the former format or the latter is yours.This is the preliminary version of your TM but generally does not serve its purpose when you stop here.Maximum benefits can be reaped from it when you extrapolate it all the way to defects.Lets see how.For each test scenario that you came up with, you are going to have at least 1 or more test cases. So, include another column when you get there and write the test case IDs as shows below:

At this stage, theTraceability Matrix can be used to find gaps. For example, in the aboveTraceability Matrix you see that there are no test cases written for FSD section 1.2.As a general rule, any empty spaces in theTraceability Matrix are potential areas for investigation.So a gap like this can mean one of the two things:1. The test team has somehow missed considering the Existing user functionality.2. The Existing user functionality has been deferred to later or removed from the applications functionality requirements. In this case, the TM shows an inconsistency in the FSD or BRD which means that an update on FSD and/or BRD documents should be done.If it is scenario 1, it will indicate the places where test team needs to work some more to ensure 100% coverage.In scenarios 2, TM not just shows gaps it points to incorrect documentation that needs immediate correction.Let us now expand the TM to include test case execution status and defects.The below version of the Traceability Matrix is generally prepared during or after test execution:

Important Points to Note about Traceability MatrixThe following are the important points to note about this version of the Traceability Matrix:1)The execution status is also displayed. During execution, it gives a consolidated snapshot of how work is progressing.2)Defects: When this column is used to establish the backward traceability we can tell that the New user functionality is the most flawed. Instead of reporting that so and so test cases failed, TM provides a transparency back to the business requirement that has most defects thus show casing the Quality in terms of what the client desires.3)As a further step, you can color code the defect ID to represent their states. For example, defect ID in red can mean it is still Open, in green can mean it is closed. When this is done, the TM works as a health check report displaying the status of the defects corresponding to a certain BRD or FSD functionality is being open or closed.4)If there is a technical design document or use cases or any other artifacts that you would like to track you can always expand the above created document to suit your needs by adding additional columns.To sum up, a requirements traceability Matrix helps in:1. Ensuring 100% test coverage2. Showing requirement/document inconsistencies3. Displaying the overall defect/execution status with focus on business requirements.4. If a certain business and/or functional requirement were to change, a TM helps estimate or analyze the impact on the QA teams work in terms of revisiting/reworking on the test cases.Additionally,1. A TM is not a manual testing specific tool, it can be used for automation projects as well. For an automation project, the test case ID can indicate the automation test script name.2. It is also not a tool that can be used just by the QAs. The development team can use the same to map BRD/FSD requirements to blocks/units/conditions of code created to make sure all the requirements are developed.3. Test management toolslikeHP ALMcome with the inbuilt traceability feature.An important point to note is that, the way you maintain and update yourTraceability Matrixdetermines the effectiveness of its use. If not updated often or updated incorrectly the tool is a burden instead of being a help and creates the impression that the tool by itself it not worthy of using.