The Value of Traceability

🗄️ Archive
1

I have the question about the use and value of traceability. To help clarify my use of the word, I mean the ability to link or trace a test case to a requirement or a test case to a defect.

I have seen some very strict usage of traceability to the point that the amount of administration to use it does not seem beneficial. In my own practice, I’ve rarely or never used traceability.

My question is what is the value and benefit of traceability in testing?

Thanks!
Joe

2

Hi Joe
Coincidentally, I was thinking about this same thing this morning and saw your post.
Theoretically, it seems good to have traceability but I find two challenges on the way to do so:

  1. Requirements are not modular, they are dependent on each other so segregating test cases to match exactly is a bit of a task.
  2. I have hardly ever seen anyone revisiting the test case and finding a related defect and doing something useful out of it. I am curious to know how many did that!
  3. I think that maintaining traceability is a time consuming task- and these days because of tools like JIRA, it is anyway easier to track back with the unique IDs, if needed be.
3

Hello @prachijain.me!

All good points! I especially like point 2. I rarely get asked about past test executions; others have told me they have been asked about them mostly to verify coverage.

If tools are doing the tracing for me, I have no issue. I still question the value.

Thanks!
Joe

4

We used to tag every requirement in the functional design specs, and state in each test case which requirements the test case applied to. Because the test documents, at the time, were written in a consistent manner, a Word VBA macro would then be used to create a requirements cross reference. Even with that bit of automation, it proved an expensive way of doing things, especially at a time when margins were starting to shrink*.

Fast forward to today, and requirements are captured in Jira, grouped by functionality in sub-tasks. Test engineer and developer comments flesh out the scoping (the important part, because getting anyone to review the final test documentation is hard) and ultimately describe how the requirements will be tested. On the team I’m currently working with, this approach is actually working quite well but I think more consistent Jira usage is needed. I think it’s a good example of how a lot of the thinking that came out of the Agile movement applies to any development approach (we’re still fundamentally waterfall).

  • Reducing the cost of Professional Services remains a challenge.
5

Hi Joe,

I think I have only used traceability when I was working under a very tyrannical scrum master who loved to blame publicly the single test resource (Me) for any production bugs.

I was able to use that traceability from the original development ticket > test cases attached > screenshots attached directly related to the code change. That saved my bacon a number of times as the scrum master was an ancient developer who disliked testers. Glad I quit that job :grinning:

Actually I did use it another time when called out to please explain within a very large company in front of Ex Manager & CEO. Again I could trace everything back from development > system test > integration > inclusion to automation regression. It then came to light the issue was with the original business requirements that were not clearly defined and business had signed off on it twice. First with the concept and secondly with the demo prior to UAT release.

3 Likes
6

Indeed, Kim - most people very quickly adopt traceability when they find they’re in a blame culture :slight_smile: .

The main areas where traceability is used for good reasons - that’s ‘good’ as an absolute, not just ‘good’ for the legitimate guarding of your back! - is in systems where there is a regulatory aspect, either because of politics (regulation of privatised utilities, as in the UK), finance, or things like medical equipment software. Traceability may well be a legal requirement in these situations.

2 Likes
7

Firstly lets discuss What is Traceability? Simply – it’s the ability to trace something, e.g. processes or items. Especially useful in such industries as logistics, trading, healthcare, security, and everywhere where we have to deal with production.

Traceability is also used widely by IT industry in agile testing services. During the whole development lifecycle in agile testing services, there are a lot of spots that can cause potential problems with our product – software. For this reason traceability is inextricably connected with testing.

This is especially useful in those more complex projects where requirements frequently change or need to be refined later in the project. With the help of traceability, we can easily track the progress of the whole project or its particular stages, bugs needed to be fixed, incompatibility of functions and requirements, and other data that allows us to make sure that our software really works.

Traceability in agile testing services is the ability to trace tests forward and backward through the development lifecycle. Test cases are traced forward to test runs. And test runs are traced forward to issues that need to be fixed (or are traced forward to a passed test case). Test cases and test runs can also be traced backward to requirements. The links between the requirements, test cases, and defects that occur during test execution create consistent causal progress which is valuable to monitor.

Traceability in software testing is often done using a traceability matrix .

Traceability matrix might include:

  • Requirements, user stories, or epics.
  • Test cases for those requirements/user stories/epics.
  • Test runs (and their results).
  • Issues or defects (and whether they’ve been resolved).