Requirements Traceability Matrix: A Guide To Better QA Process
One of the most basic activities in Quality assurance is creating test cases. Having valid and up to date testing documentation allows easy testing and smooth QA process. However, there is an organizational issue here. By the definition test cases must cover all new development, meaning all the requirements or user stories if you will. There could be a lot of requirements or a larger number of QA engineers working on a project. In these cases the complexity of documentation maintenance increases. Obviously we need some kind of a system of tracking of test cases coverage for each requirement. Requirements traceability matrix is the system that is just right for solving this issue.
What is a requirements traceability matrix?
It is a simple document with tabular display of all requirements related to a release or feature or quarter. We can differentiate between 3 types of matrix:
- Forward
- Backward
- Bidirectional
All three types cover similar data but in a different display order. Forward traceability allows us to start from the requirement and make sure that all the test cases are linked to it. This way we ensure test coverage of all requirements. Backward or reverse traceability puts test case into focus as a starting point for linking all the requirements, test runs and defects. Bidirectional traceability is a combination of the previous two. It ensures the coverage of each requirement with a test case, over to test run and over to defects and over to the original ticket containing source code reference. Also ensures that the each test case can be traced through the same path back to the requirement. Bidirectional traceability matrix is what QA engineers usually create.
Benefits of traceability matrix
As already mentioned, in teams with larger number of QA engineers it is easy to lose all the requirements and test cases from your sight. We can use traceability matrix with reference to each test case and requirements to ensure test case coverage. This is a single document containing your entire project: each of the requirements, all test cases related to those requirements, bug report references and original tickets with code references. You can showcase your traceability matrix to the client during demo of your work as a proof that everything was done according to their expectations. This way you are leaving a professional impression and proactively answer some of your customer’s questions in advance. You can track your test execution and keep record about successful vs unsuccessful tests. It is an easy map for onboarding new colleagues.
Key elements of traceability matrix
There are various designs and layouts of traceability matrices and there are no wrong answer in here. It all depends on the preferences and needs of the team. Some of the most common elements are: Requirement ID, test case ID, description, test case execution status, bug report ID, development ticket ID, overall status, etc. I don’t think there is anything standard in the design of the matrix and really you cannot make a mistake if you create it based on your needs.
How to create the matrix?
There are certain aspects we need to think about when we start thinking about the traceability matrix. First you need to thoroughly discuss all the requirements with your team and with client directly if possible. Understand the requirements, ask all the questions, clear all the doubts and have a good understanding what problem you need to solve for the client.
Gather as much information and all the available documentation. Start by inserting the existing data. Usually you will have some of the requirement documents, user stories or use cases to start with. Enter those first in the matrix and then build on top of that. Add test cases for each of those requirements and add them in the matrix.
Add details about development tickets, their status maybe, add priorities for each requirement if you believe it is necessary. Above all, update the matrix on regular basis with changes. If possible store the matrix somewhere in Confluence page or on Sharepoint where the entire team can access it.
Execute tests and validate in the matrix
In the end the only thing left to do is to run the tests, report the bugs if you find any, add them in the requirements traceability matrix and follow the changes of their statuses. If all the tests related to the single requirement pass, mark the requirement as completed and enjoy being one step closer to the delivery of successful solution to the client.
