Test conditions should be able to be linked back to their sources in the test basis, this is known as traceability. Traceability can be horizontal through all the test documentation for a given test level (e.g. system testing, from test conditions through test cases to test scripts) or it can be vertical through the layers of development documentation (e.g. from requirements to components).

Now, the question may arise is that Why is traceability important?  So, let’s have a look on the following examples:

• The requirements for a given function or feature have changed. Some of the fields now have different ranges that can be entered. Which tests were looking at those boundaries? They now need to be changed. How many tests will actually be affected by this change in the requirements? These questions can be answered easily if the requirements can easily be traced to the tests.

• A set of tests that has run OK in the past has now started creating serious problems. What functionality do these tests actually exercise? Traceability between the tests and the requirement being tested enables the functions or features affected to be identified more easily.

Before delivering a new release, we want to know whether or not we have tested all of the specified requirements in the requirements specification. We have the list of the tests that have passed – was every requirement tested?

Other popular articles:

• What is Maintainability testing in software?
• What are Test Conditions & Test Analysis? Advantages, Disadvantages & Level of Detail
• What are the different Agile Testing Methodology? Test Driven Development, Behavior Driven Development
• What is a Defect Life Cycle or a Bug lifecycle in software testing?
• What is documentation testing in software testing?