SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 2 of 2
  1. #1
    Senior Member
    Join Date
    Nov 1999
    Location
    CA
    Posts
    187
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    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?

    ------------------

  2. #2
    SQA Knight
    Join Date
    Jan 2002
    Location
    Highlands Ranch, CO, USA
    Posts
    2,860
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    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.

    Jim


    ------------------
    Jim
    -------------------------------------------
    For all the general stuff to know about QA/Test go here http://www.softwareqatest.com/

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 13.64%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 09:56 PM.

Copyright BetaSoft Inc.