How to link test result in RQM with configuration( 2 streams) to RTC defect with the same iteration
Hi Someone who may concern,
We developed RTC project first, and for different model year, we used the same iteration.
i.e for example, sprint 1.1.1 ( 01/01/2018-01/14/2018)
Then later, we developed RQM project, and create 2 Global Configuration streams based on model year, say stream1: xxx_for_2018, xxx_for_2019 which include RQM local streams for 2018 and 2019 separately.
Then I found we can not create links between test case result in this 2 streams to RTC defect.
Because RTC has no configuration, we need to go to Releases section in project area, mapping relationship between iteration in RTC to GC stream, which is 1 to 1, i.e. 1 iteration can only map to 1 GC stream.
say, we map GC stream 2018 to iteration sprint 1.1.1 in RTC, then when we create link between test result in RQM in 2018 stream to defect in RTC with iteration as sprint 1.1.1, then the link is valid, i.e. when you click the link from RTC side, you can go to correct test result in RQM in 2018 stream.
However, if we want to create link from RQM in 2019 stream to the defect with iteration as sprint 1.1.1, then the link will be invalid, i.e. when you click the link from RTC side, you can not to to correct test result in RQM in 2019 stream. because sprint 1.1.1 is mapped to 2018 stream. I have checked, the link on defect link page has no configuration information. so, it depends on mapping.
We are thinking how to resolve the issue.
One way is to separate sprint according to model year,
i.e. sprint 1.1.1 for 2018 and sprint 1.1.1 for 2019
However, we already have thousands of records already, we need to separate them manually.
And our developer team do not want to select sprint according to model year, because it means PO has to work on doubled plans, and need to separate resource management on 18 and 19, which is not reasonable.
So, we are wondering whether any other way we can workaround the issue?
Thanks!
Best Regards,
Jane Zhou
Accepted answer
Jane,
read https://www.ibm.com/support/knowledgecenter/SSYMRC_6.0.5/com.ibm.team.workitem.doc/topics/t_enabling_linking_to_versioned_artifacts.html
"Derived from Planned For" is only one way to map the links in work items pointing to configurations. You can either use a custom deliverable attribute or e.g. use Found In. You should be able to create release objects pointing to different global configurations without getting the iteration into the mix as long as you map no link types to "Derive from Planned For"
There is still the restriction that a particular work item will use one and only one global configuration to resolve the versioned links. At least you can have a defect A selecting release_2018 and a defect B selecting release_2019 which are both part of sprint 1.1.1 and a single plan.
If you link the two defects related or put them as children of a master parent defect would this fulfill your requirements around usage and reporting?
"Derived from Planned For" is only one way to map the links in work items pointing to configurations. You can either use a custom deliverable attribute or e.g. use Found In. You should be able to create release objects pointing to different global configurations without getting the iteration into the mix as long as you map no link types to "Derive from Planned For"
There is still the restriction that a particular work item will use one and only one global configuration to resolve the versioned links. At least you can have a defect A selecting release_2018 and a defect B selecting release_2019 which are both part of sprint 1.1.1 and a single plan.
If you link the two defects related or put them as children of a master parent defect would this fulfill your requirements around usage and reporting?
In case the answer is helpful please mark it as accepted.
- Arne