3 Reasons Why You Shouldn’t Trace Your Tests to Requirements

Trace your Tests to Requirements

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.

See also:


  1. Adam Grant says:

    These seem like temporary excuses at best. The fact that they are presented here for general consideration is an indication that test efforts routinely fall behind the development cycle, thus crippling their effectiveness. Perhaps a more interesting discussion would be how to avoid having to make these excuses in the first place.

  2. Goran Begic says:

    Thanks for the comment Adam. I don’t know if this post indicates the state of test efforts. I do think that our industry needs a more open discussion about some of the best practices because ultimately the removal of taboos will lead to a wider and healthier adoption. A friend reminded me that sometimes there are real obstacles towards adoption of traceability and not just perceptions and I updated the post to reflect that. Btw, here is another, related post discussing the benefits of requirements traceability: Requirements Traceability: Why Bother

  3. 安いグッチのバッグ  

  4. 安いグッチのバッグ  

Speak Your Mind