The Value of Traceability

Questions
#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.

2 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