On a rather large integration project someone came up with a similar idea for tracking actions / dependencies. The idea was that these could be raised as Dependency Defects, which were essentially the same as normal defects but with a root cause of Dependency defined. Any actions blocking the completion of a test script could then be failed against that dependency.
Sounds good on the face of it, but in practice it became a management and administrative nightmare. This is partly down to the process the programme chose to follow (ie. dependencies centrally administered) but also down to the fact that the testing workflow preferred by HP QC doesn't lean that way so easily.
Key issues we encountered:
- Unclear ownership: People were unsure where to assign tasks when the action was no longer with them. We found that we'd need to increase our license coverage in order for more and more people to be added in.
- Duplication: Quite often we found that we had a task defect raised that also covered the actions within a bona fide code defect. This meant that we were getting updates added inconsistently depending on which defect a person was aware of.
- Administration: Due to point two, there were defects of all kinds cross linked and referenced all over the place. It required a team of people just to administer that and keep it tidy.
My advice would be that if you are using a project in HP QC solely for tasks, you should be fine. If you will be mixing defects and test management functions as well, I'd think twice.
Hope that helps!
