The simplest guide to creating a traceability matrix for QA

One of the most helpful ways to document your product for QA is by creating a traceability matrix. A traceability matrix is exactly what it sounds like: a handy grid that allows you to trace which of your test cases map to which of your product features and requirements. It basically takes your product and breaks it up into simple, digestible parts, and lets you check that you (or whoever is doing QA) are testing it fully.

Feeling lost? Don't worry. This article will explore exactly how to create a simple traceability matrix and why you would want to do so in the first place.

What the heck is a traceability matrix? 😆

Simply put – a traceability matrix is just a table (usually created in a spreadsheet) where you can track which of your QA test cases (check out our handy guide to test cases) relate to which of your product features. That way you can make sure your test cases cover 100% of your product's features, even the small ones people often forget about, like for example, updating obscure account settings.

Technically there are differences between a traceability matrix and a requirements traceability matrix (RTM) but QA and project managers seem to use the words interchangeably. To add to the naming confusion, it's also sometimes referred to as a Cross Reference Matrix. But it all means the same thing: a table mapping what QA is testing to what product & engineering are building.

Traceability matrixes can be used in project management to track business requirements vs product features to make sure all the original business requirements are met. But in QA, they are used to track test cases vs product requirements or features.

Below is a helpful example of a QA traceability matrix by the folks at softwaretestingmaterial.com:

As you can see above, a traceability matrix is a chart that shows all the connections between the various parts of your product, and your QA test cases. On the left, you see each of your test cases, by test case ID. And on the right, you see each of the product or business requirements (e.g. "User can update their password in account settings").

Think of it as a map for your app in table form, to help you QA.

Why traceability matrixes are important

Building a traceability matrix for your product QA can be helpful in many ways:

1. To track revisions of requirements over time

Products grow in scope over time, so your original list of test cases may get stale or insufficient over time. One of the challenges of QA is tracking those changes and making sure you test cases are up to date and genuinely test the whole product.

You can track changes in requirements over time by adding new rows to your matrix. This will help you identify when something changes, how it affects other test cases that are dependent on it.

It's also an easy table to share between QA and product so that product can see visually that QA knows about and is testing all the new product functionality, and point out any functionality they spot is missing.

2. To determine what should be included in testing

Traceability matrixes help you keep track of requirements so you can test them. Without them, crucial features may be forgotten and, thus, remain buggy because no one ever tested them (you'd be surprised how often this happens).

4. To make sure you have 100% test coverage

Especially when a product has a lot of scope & features, it can be hard to check that your test cases cover 100% of them. Traceability matrixes are especially good for that. In one table, you can see every product feature and how many test cases cover it.

Types of traceability matrixes

There are some fancy names for the three different types of traceability matrixes. Here's the most basic explanation of each one:

Forward traceability matrices

Maps requirements to test cases. It's called "forward traceability" because it's done ahead of time – before the product is built. It's useful for making sure your test plan is complete, that your test cases cover 100% of the product functionality.

Backwards / reverse traceability matrices

Maps test cases to requirements. It's called "backwards" or "reverse" because it's the opposite line up of forward matrixes (instead of requirements to test cases, it's the opposite – test cases to requirements).

Also, it's typically done after the fact, after a product is built. It looks at the current, existing test cases and maps them to the current existing product. It makes sure that all the requirements have appropriate test cases. It's helpful for making sure you have 100% test coverage.

Bi-directional traceability matrices

Maps requirements to test cases and test cases to requirements. It's forward and backward. It's just a truly giant matrix of test cases and features.

How to create your own traceability matrix

Here's how to create a traceability matrix yourself:

Step 1: The first step is to note down all your product requirements (and I mean all – that way you can make sure your tests cover the whole surface area of your product).

Step 2: Create a table that has columns for the requirement ID, requirement type and description, test cases, test case statuses, and any extra information you want to include.

Step 3: Add new rows for each requirement and fill these out appropriately.

Step 4. Save your matrix somewhere. It's a living document - you'll probably want to add to it later as your product changes. A pro tip is to save it as a template somewhere so that each time you run through your tests you can mark whether each test passed or failed against each product requirement.

~ Psst – doing QA? Jam is a tool that helps you capture and document bugs faster, saving you lots of time and manual work. Check it out at jam.dev. ~