Test Execution & Blocker Status
I'm afraid I fail to see the point of the "blocking" statu other than from a visual perspective.
I had hoped that if I placed an execution record in blocking status that the system would prevent me from re-executing until such time as the defects had been resolved ... that doesn't appear to be the case .. did I miss something ?
I had hoped that if I placed an execution record in blocking status that the system would prevent me from re-executing until such time as the defects had been resolved ... that doesn't appear to be the case .. did I miss something ?
4 answers
Hi Karen,
It could also be used as an important piece of reporting data for multiple scenarios.
In addition, check out Praveen's post here: http://jazz.net/forums/viewtopic.php?t=6722
If you are using C/ALM with both RTC defect and build integration, we have the capability to move blocked TERs to unblocked automatically when a build is completed that has fixes for a defect in it. Pretty cool!
Regards,
John
It could also be used as an important piece of reporting data for multiple scenarios.
In addition, check out Praveen's post here: http://jazz.net/forums/viewtopic.php?t=6722
If you are using C/ALM with both RTC defect and build integration, we have the capability to move blocked TERs to unblocked automatically when a build is completed that has fixes for a defect in it. Pretty cool!
Regards,
John
I'm afraid I fail to see the point of the "blocking" statu other than from a visual perspective.
I had hoped that if I placed an execution record in blocking status that the system would prevent me from re-executing until such time as the defects had been resolved ... that doesn't appear to be the case .. did I miss something ?
Hi Karen,
It could also be used as an important piece of reporting data for multiple scenarios.
In addition, check out Praveen's post here: http://jazz.net/forums/viewtopic.php?t=6722
If you are using C/ALM with both RTC defect and build integration, we have the capability to move blocked TERs to unblocked automatically when a build is completed that has fixes for a defect in it. Pretty cool!
Regards,
John
I'm afraid I fail to see the point of the "blocking" statu other than from a visual perspective.
I had hoped that if I placed an execution record in blocking status that the system would prevent me from re-executing until such time as the defects had been resolved ... that doesn't appear to be the case .. did I miss something ?
Hi John
After reading a few other topics on the same subject it appears that the blocking feature is more geared to integration with RTC - and doesn't work as expected if you're not using that integration .. would that be a fair statement ?
Hi Karen,
I think the more accurate statement is that automatic unblocking only occurs when the RTC build integration is used. You can still use blocking for tracking and reporting use cases without the integration.
I think an enhancement request to have an optional setting to unblock on defect resolution directly, rather than having a completed build that contains the associated defects, would be fair and beneficial.
Regards,
John Nason
Hi John
After reading a few other topics on the same subject it appears that the blocking feature is more geared to integration with RTC - and doesn't work as expected if you're not using that integration .. would that be a fair statement ?
I think the more accurate statement is that automatic unblocking only occurs when the RTC build integration is used. You can still use blocking for tracking and reporting use cases without the integration.
I think an enhancement request to have an optional setting to unblock on defect resolution directly, rather than having a completed build that contains the associated defects, would be fair and beneficial.
Regards,
John Nason
Hi Karen,
It could also be used as an important piece of reporting data for multiple scenarios.
In addition, check out Praveen's post here: http://jazz.net/forums/viewtopic.php?t=6722
If you are using C/ALM with both RTC defect and build integration, we have the capability to move blocked TERs to unblocked automatically when a build is completed that has fixes for a defect in it. Pretty cool!
Regards,
John
I'm afraid I fail to see the point of the "blocking" statu other than from a visual perspective.
I had hoped that if I placed an execution record in blocking status that the system would prevent me from re-executing until such time as the defects had been resolved ... that doesn't appear to be the case .. did I miss something ?
Hi John
After reading a few other topics on the same subject it appears that the blocking feature is more geared to integration with RTC - and doesn't work as expected if you're not using that integration .. would that be a fair statement ?
Hi Karen,
I think the more accurate statement is that automatic unblocking only occurs when the RTC build integration is used. You can still use blocking for tracking and reporting use cases without the integration.
I think an enhancement request to have an optional setting to unblock on defect resolution directly, rather than having a completed build that contains the associated defects, would be fair and beneficial.
Regards,
John Nason
Hi Karen,
It could also be used as an important piece of reporting data for multiple scenarios.
In addition, check out Praveen's post here: http://jazz.net/forums/viewtopic.php?t=6722
If you are using C/ALM with both RTC defect and build integration, we have the capability to move blocked TERs to unblocked automatically when a build is completed that has fixes for a defect in it. Pretty cool!
Regards,
John
I'm afraid I fail to see the point of the "blocking" statu other than from a visual perspective.
I had hoped that if I placed an execution record in blocking status that the system would prevent me from re-executing until such time as the defects had been resolved ... that doesn't appear to be the case .. did I miss something ?
Hi John
After reading a few other topics on the same subject it appears that the blocking feature is more geared to integration with RTC - and doesn't work as expected if you're not using that integration .. would that be a fair statement ?
Hi John
Thanks for the clarification ... I personally think we're placing a lot of assumptions here that people will be using both RQM and RTC - the features that we've enabled for blocking defects with this mechanism, really do need to be replicated in RQM as a standalone tool, on the assumption that the client may be using just RQM for requirements and defect management ...