defect/CR goes to dev.
dev fixes, marks as fixed.
get released to QA, pushed to test build.
We test and either pass or fail.
if fail, goes back to dev, then they fix, the cycle continues.
many times, we have to fail an issue because the developer messed up the build process, put in the wrong branch, etc.
sometimes the spec might change during development, or someone really important needs it tweeked before releasing. so in these cases, we must fail the issue.
i am trying to come up with some fair "reasons" for an issue to be failed. such as:
what others would be good to have for most cases?
the goal here is to be able to better report on issues, right now, i run a report on failed items but would like to be able to eliminate build issue related failed items from the reports, for example.
alot of issues are pushed back and forth between dev and QA but from a (failed issue)reporting perspective, it just looks bad for the developer and i think that making some changes to this will have a good impact on the qa/dev relationship.
Without looking at the report I don't know if this is possible, but couldn't you include the fail reason?
I wouldn't want to not include the things that failed due to build issues, just because it would be useful. It could be use to identify recurring problems that could be looked at or maybe something bigger is being masked.
If people were able to see the fail reason for a particular failure, and be able to note that it was a build issue.
Why are these even getting reported as fails? They shouldn't be - pass them based on the scope in which they were worked - then redefine their status where (as is common with TestDirector users) the Reviewed status is changed to "Changed" to indicate that the requirement itself is different. The execution status could them be changed to failed and a new bug opened. May sound like semantics but the point is to show that the developers are doing their jobs - they are fixing the problems as they understand them - at the time they are worked - scope changes/creep cause changes and this can be reflected in a report showing all those reqs that were "changed" - regardless of how - that info can be placed in the notes or the new field you made up.
To obtain practical reasons for failure go back over the defects created on several projects and analyze them. You will get reasons that actually happen and fit in your environment. Be prepared that you first pass at this will need improvements.
I have not failed. I've just found 10,000 ways that won't work" --Thomas Edison