Its always said that the requirements should be traceable but when we talk about agile development, it is quite difficult. My question is that how requirement traceability (or requirement change management) is managed in agile and specifically Test First Development or Test Driven Development?
Requirement Traceability in TDD?
2.1k Views Asked by Abrar At
6
There are 6 best solutions below
2
On
May be I am missing something but TFD or TDD is at the unit testing level. What you are referring to is managed by Traceability matrix and/or acceptance tests in my opinion.
0
On
When the requirements change, the tests change. Remember that the tests are the living documentation and requirements specification. Therefore, the change is seamless.
For example: Requirements changes lead to test expectation changes, which in turn lead to code changes.
0
On
Agile traceability is very tricky to begin with, A lot of tools are currently available that claim to provide traceability by documenting user stories, or generating requirements from user stories or in TDD from Tests.
The point when we consider any Agile method is not having to emphasize on documentation(Read the Agile Manifesto. So, I am not sure how Agile will have traceability and also streamline with its core principles.
0
On
Lately found a traceablity, requirement management tool online. [http://code.google.com/p/ultimate-trace/ Ultimate Trace] Give it a try. It saved us a lot of effort maintaining traceability.
0
On
Re-read the manifesto. It values the right-half of the four statements more, but note that it reads, "there is value on the left." Which means that documents are not inherently evil or forbidden, they should just be view cautiously and should not overrule the real purpose of the work. That being said, electronic traceability tools have been out there for years, some more elegant and some absolute beasts. Tracking from test cases back to the stories defining them is important, especially as systems move into R&M. Otherwise, as systems grow you trade off chasing down documentation of the system for chasing down components of the system. Traceability may be handled by naming conventions, some feature of a configuration/code baseline tool, by a test suite tool, or by an RTM. The old, old school approach was an spreadsheet (slit my wrists, please), but we have come a long way by now.
In TDD or BDD (Behavior Driven Development) your requirements are captured in your tests.
You can either map your tests against actual requirements (more TDD model) or actually use your tests as the requirements for your product (more BDD model).
For a great example of what you can do with BDD and tests functioning as requirements, checkout RSpec and Cucumber from the Ruby/Rails world.
Having worked in an FDA regulated environment, with responsibility for Quality Engineering, I can tell you that TDD/BDD fits incredibly well into the model an FDA Auditor is working against.
A BDD model will allow you to trace through: