[PROPOSAL] QA Prioritization on Reports

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[PROPOSAL] QA Prioritization on Reports

Dennis E. Hamilton-2
Hi Alex,

Thank you for your willingness.

I don't think we are as organized as you seem to be thinking (and happy to be mistaken).

I am providing a proposal in response to your great question.

This may be too many words. All assistance in making this clear, with any questions, suggestions, objections, whatever: please provide on this thread.

 - Dennis


We have a growing backlog (also known as a technical debt) and an useful way to deal with that is,

 1. Stop (by progressively reducing the rate of growth of) the growth of the backlog.  That means looking at new ones to see how they can be confirmed, and resolved or assignable to a developer in the case of confirmed defects.  (Even if you are prepared to work on it and own it, follow these stages so others know what is going on.)

 2. Work on the older ones (what is called technical debt as they age).  I would suggest, in particular, older ones for which (1) duplicates keep showing up or (2) there is still ongoing comments against them.  There are ways to detect those, but watching the OOo-issues list is a big start.  I assume everyone on the QA list is also subscribed to <[hidden email]>.

 3. GOOD PRACTICE.  Because this is a self-organizing voluntary effort, what I recommend is that, when an issue or block of issues is taken on for QA scrutiny, post a message *here* announcing the numbers or ranges that are being taken on.  Also, add yourself as the QA contact on the issue, so others know there as well.  That provides a heartbeat and indication that others should look for low-hanging fruit elsewhere.  When you are done with ones you have examined (no matter what the outcome), announce that and adjust the QA contact on the issue if necessary.

I think that is an ideal practice, all other factors considered.


When the project is driving for a release, there will be release blockers.  Keep an eye on those.  Also, be prepared to do a regression test, if possible, to confirm whether the release candidate appears to cure the defect or not.  This should involve follow-up at the issue.  Not all reporters are in a position to install release candidates in a safe way.  When the release happens, that is a good time to see if the reporters can then update and confirm whether the problem is cured.  

-----Original Message-----
From: Alex Korsakov [mailto:[hidden email]]
Sent: Friday, September 18, 2015 04:11
To: [hidden email]
Subject: [QA]Some batch of reports

Good day to all! I'm a newbie in a QA, but I understand "how it works"
and already work with unconfirmed defects in Bugzilla, but I wanna ask
you to assign to me some batch of reports. I think it would be more
productive for me. Thanks.

PS sorry for bad English

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]