Any document detailing whether TCER and the underlying configuration have 1:1 relationship?
I have discussed with colleagues about this and found that in RQM it is implied that for a configuration (unique combination of test plan, test script and etc), there can be only one TCER for the test case. Do we have any documents actually explaining this in details?
Put it in context, when running a test case directly, you have the option "New Test Case Execution Record", and it will create a new TCER based on the selection of test plan and etc. If you run the test case for a second time and happen to do exactly the same thing, actually no new TCER is created, and the test result will be added to the previously created TCER.
We know it _should_ be like this, but some end users find it hard to understand. Do we have any documents to back this up?
Put it in context, when running a test case directly, you have the option "New Test Case Execution Record", and it will create a new TCER based on the selection of test plan and etc. If you run the test case for a second time and happen to do exactly the same thing, actually no new TCER is created, and the test result will be added to the previously created TCER.
We know it _should_ be like this, but some end users find it hard to understand. Do we have any documents to back this up?
Accepted answer
Hi Donald,
You might find this article about the relationship between Test Suites, Test Plans, Test Cases and TCERs
http://sleroyblog.wordpress.com/2013/05/22/a-rqm-usage-antipattern-multiplying-nonequiv-test-scripts-associated-to-a-test-case/
goes some way to answering your questions. It will probably help your users understand better how to architecture their tests in RQM.
Simon
You might find this article about the relationship between Test Suites, Test Plans, Test Cases and TCERs
http://sleroyblog.wordpress.com/2013/05/22/a-rqm-usage-antipattern-multiplying-nonequiv-test-scripts-associated-to-a-test-case/
goes some way to answering your questions. It will probably help your users understand better how to architecture their tests in RQM.
Simon