[Ron]

I noticed Shaykat (over in the C#/debugger team) posted about bug bounces.  For our test team., these come in threes.

The first one we encounter is ZBB - zero bug bounce.  This is driving active product bugs down to zero.  This is the bug bounce that Shaykat is talking about in his post.  Test is involved in this bounce becuase sometimes we have active bugs assigned to us.  These could be bugs where the dev is asking for more information or a repro case or, in some minor cases, it could be because test owns development of some product areas.

The second bounce is ZRBB - zero resolved bug bounce.  This is driving the resolved product bugs down to zero (i.e., verifying and closing them).  Bugs in this category are important because, until the fix is verified, we can't be totally sure it's fixed or hasn't caused some other regression.  Testing tends to be the most heavily involved in this bounce since (ideally) they have opened most of the bugs and would be the ones to verify the fixes.  They are also involved in bugs that weren't opened by testing since those bugs should cause us to ask why we didn't find those bugs and add to our testing if that indicated a test hole.

The third and final bounce is ZTBB - zero test bug bounce.  This is driving the active bugs against our test automation down to zero.  This is important since a test that isn't working can't find bugs or verify the funtionality of the product.

This last bounce doesn't get as much attention as the other two; it's generally only an effort for the test team but we do treat our test automation as a real development project.   That means our test automation code is checked into a source code control system, bugs against our automation go into an issue tracking database, and we do periodically drive our bug count down to make sure we're not missing issues or test coverage.