Which Bugs Do You Report on At Interim Bug Review Meeting?
During the test phase, there are of course numerous bug review meetings held. At the first one, I usually print out lists of all the bugs currently logged against a release. But I'm unsure of the best approach for subsequent bug reviews, after the first one. Some managers want "all bugs modified or newly created" since the last bug review meeting. Some only want a list of the new or assigned bugs, regardless of whether they were modified since the last bug review. The latest request is to print a list of all the P3 or lower priority bugs that are new or modified, since the last bug review meeting and then a separate list of all the open P1 or P2 (higher priority bugs which we wouldn't release with) for each bug review meeting.
Thoughts on best approach?
Re: Which Bugs Do You Report on At Interim Bug Review Meeting?
On the initial go round for a project you will want to print out and review the current outstanding defect reports (from previous release testing and new ones reported against production). From this you will track those assigned to be "fixed" for the release, and anything new that comes out of internal testing. Maybe a new production defect if it is severe enough (meaning how high risk for support calls).
As part of the reporting break out your defect reports by status and then Severity. New defects first and then Open. Have the high severity defects listed first and go in descending order. The reason to review the Open defects is to keep them on the radar and make sure they get resolved in a timely fashion (can't tell you how many times Open status defects have stayed on a list for a long time due lack of exposure). Because a lot of times waiting to fix a bug can cause others to get backed up in the pipe and cause delays, or worse.
Your going to have to feel this out and go through a release to really see how other people involved in the review process want to view and manage this process. Create a process flow model for defect resolution and its associated statuses along the way. Get the groups buy in and support. It will be a little painful at first, but once people are "happy" with it your work will be easier.