While implementing TD to our testing environment, we have realised that our existing processes for mapping requirements to test cases might not be practical using this tool...
Typically, tracing from requirement to test case goes like this for us...
[one] (Business) Requirement
maps to -->
[one] Test Objective
maps to -->
[many] Test Cases
If we were to continue mapping in this way, does anyone have any recommendations as to how to record this in TestDirector? Our initial leaning is to store Business Requirements as 'Parent' requirements in Test Director, Objectives as 'Child' requirements, and then 'Test Cases' as expected.
Are there any obvious issues with this approach? It appears we can extract requirements (to document) either at a Parent or Child level - is this right?
Re: Test Objectives
I have all users treat the Requirements in the Requirements module as "Test Requirements". All Test Requirements map in form to the external Business Requirements. It's not a perfect world in that there isn't a programatic link to BR's, but it does ensure that everything in TD is a TESTING asset and is owned completely by QA or QE.
I can see how mixing like you describe would cause issues.