6.6. Forward vs Backward Traceability

From requirement → test case (Did we test this?)

Forward traceability refers to the process of tracking the progress from specific requirements through to the associated test cases. It helps QA teams confirm that they have covered all necessary tests related to a requirement. Essentially, it answers the question, 'Did we test all of the things that we were supposed to test based on our requirements?' This is crucial because it ensures that every intended functionality is validated.

Imagine you're packing for a trip, and you have a checklist of items to bring. Forward traceability is like checking items off your list as you pack them into your suitcase. If your list says you need a toothbrush, you can verify that you packed it by checking it off. If it's checked, you know you’ve packed it and you’re good to go!

From test case → requirement (Why are we testing this?)

Backward traceability is the process of ensuring that the test cases can trace back to their respective requirements. It allows QA teams to understand the purpose of each test case by linking it back to what requirement it fulfills. This perspective helps in validating the necessity of each test, essentially answering the question, 'Why are we testing this particular functionality?' This is important as it ensures that tests align with the original intentions of the requirements.

Continuing with the trip analogy, backward traceability is akin to looking at the items you packed and asking yourself, 'Why did I bring this item?' If you packed a camera, you might remember that your requirement was to capture memories from your trip. This ensures everything packed serves a purpose related to your trip's goals.

A good RTM supports bidirectional traceability.

Bidirectional traceability means that you can trace requirements both forwards and backwards using the Requirement Traceability Matrix (RTM). It is essential for completeness in testing because it not only checks that every requirement has been tested, but also ensures that all test cases are directly related to a requirement. This dual check provides assurance that nothing is missed in both testing and requirement fulfillment.

Think of bidirectional traceability like a feedback loop in a learning environment. As a student, you complete assignments (test cases) to prove you've understood course material (requirements). Your teacher can then look at your completed work and trace it back to the lessons taught, ensuring that everything you learned has been assessed appropriately.

Let’s say the requirement is: REQ-004: "The user shall be able to add up to 5 items to the wishlist." You should have: ● TC-010: Add 1 item → Success ● TC-011: Add 5 items → Success ● TC-012: Add 6th item → Error displayed All mapped to REQ-004 in the RTM.

In this example, the requirement specifies a functionality related to a wishlist. The associated test cases verify if the functionality works correctly. TC-010 validates adding one item, TC-011 checks the maximum (five items), and TC-012 tests the limit by adding a sixth item, which should display an error. This mapping of test cases to the requirement ensures that each condition of the requirement is thoroughly tested.

Consider a restaurant menu that lists various dishes you need to prepare. The requirement is to have five main courses on the menu. Your test cases check if you can prepare each dish successfully. For example, preparing a dish for one member of a family of five (TC-010) and ensuring every guest can choose from five options (TC-011), but trying to cook a sixth dish (TC-012) may show you have exceeded your menu limitation. This example illustrates the importance of mapping tests to requirements to ensure every scenario has been considered.

--