If you’ve been in the quality assurance business for a few project cycles, surely, at some point, you participated in a discussion about the needs for requirements traceability. What were the takeaways from the discussion? Do you trace test cases and test results to requirements?
Well, here are a few of the top excuses, barriers, or genuine arguments for not doing requirements traceability:
1. You don’t have requirements to link to
Requirements need to be unambiguous, actionable and testable. They can’t be too detailed, but they can’t be too general either. They should reflect the end-user’s needs even if these needs change over time. If you don’t have solid requirements, or if they’re out of date, then you don’t need to trace your test cases to them.
2. You’re not sure how your project would benefit from traceability information
One clear use case for requirements traceability is that you have to create it for certification purposes. This can be accomplished with help of a skilled intern at the end of the project. The “requirements keeper” puts together a couple of spreadsheets that show how functional requirements or Agile stories correspond to key product components and the existing test cases. Done!
Are there any other uses for traceability information? If you aren’t sure, or if you don’t know how else your team could benefit from traceability information, then you may not need it!
3. You have too many bugs to worry about anything else right now
The last three builds didn’t compile, and the last two weekly ones won’t install on half of the test machines. Those installations that do work crash erratically in main use cases. Your subcontractor just announced a delay, and the release date was pushed back to provide more time for a stable build. If this is your current situation, requirements traceability is the least of your problems.
Note that the above reasons point to some fundamental challenges that you would need to address before you can start improving your process. However, if you’ve got most of these problems ironed out, requirements traceability could become a great ally for you.
Where are you with your current project? Do you trace your test cases to requirements? Why or why not? If you’ve got a few minutes, we’d love to hear some of your use cases. Please feel free to share them with us in the comments section below.