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?
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:
- Requirements are not modular, they are dependent on each other so segregating test cases to match exactly is a bit of a task.
- 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!
- 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.
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
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.