Why you don't verify a bug on an unaccepted build
I know this is a best-practice, but I need to develop a good 'reason' why it is.
We do regular 'builds' of the product. Each build gets run through a BAT (Build Acceptance Testing), some places call this a smoke test.
The purpose is to give the build a quick test to confirm that it isn't a 'bad' build and can be used by the entire QA/Dev team. It either gets Accepted or Rejected.
Bugs should only be verified and closed on an Accepted build.
Why? Because if you verified/closed the bug on a build that goes to BAT and gets Rejected, then your verification is invalid.
What other reasons are there for only verifying bugs on Accepted builds?
Ideally bugs should only be fully closed after a release. This way you have change tracking end to end in the release flow. This probably makes tracking a bit complicated since you'll have to add additional states to track dev complete, QA approved, accepted (as it brought into the release candidate), and finally closed on release.
Originally Posted by Wolfeman13
But to keep it simple, most organization will closed bugs upon formal delivery of the product. Reason why you don't close bugs as part of the build pipeline is because at any time, the code could be reverted. For example. say something is fixed but broke something else that's more critical. The change is immediately reverted undoing the bug fix.
An Unaccepted build generally cannot have bugs verified on since you don't even take it as a build to test against. Builds you do not test against, you cannot verify on either. Also the fact that it's rejected means some major bugs were introduced and the bug fixes/breaks could have been the cause of the bug you are verifying against.