QA proposal for bugs
James Richard Tyrer
tyrerj at acm.org
Thu Mar 11 21:43:38 CET 2004
This is only for current reported bugs. I fully realize that other testing
in also needed -- specifically regression testing.
My basic idea is to have a distributed QA system based on one of these
instances for the verification of a given bug:
1. The bug reporter doing the job (if he built from source).
2. A Quality Team member adopting the bug and doing the job -- being
an advocate for the bug.
3. The maintainer requesting that the Quality Team verify the fix, and
a Quality Team member taking the job from a posted 'to do' list.
4. TQM, the maintainer would do the job.
After the bug is marked as fixed, one of the above persons should verify
that the bug is fixed and either mark it as VERIFIED or request that the
maintainer or his supervisor on the Quality Team reverify it and mark it as
VERIFIED (or if it isn't FIXED, then REOPEN it).
This verification must be based on a very definitive test case, or cases.
This test case, or these test cases, must be posted on BugZilla. These
should be added as soon as possible after the bug is first opened.
Additional suggestions:
The person(s) that verify the bug should be added as CC's.
The person that is managing the bug should be added as CC and
maintain a formal 'to do' list of those bugs he is watching and
which bugs he is waiting to verify.
The test cases should (after verification) be added to a regression
database for possible future use.
The person that verified the bug should if possible do regression
testing of the test cases from that bug on future release
candidates and releases, and reopen the bug with the notation that
it is a REGRESSION if needed.
In case #2, the advocate should follow the bug's CC's and add
additional comments as appropriate.
Some effort should be made to set the severity and priority of the bug.
A policy should be established to always do this with
regressions.
================
Comments:
This is based on our standard operating procedure of constructive anarchy.
The only structure needed to start it is a process for #3 and we could
start it without that. I can start my part this evening if I get the go
ahead. I have three bugs on my 'to verify' list and I need to sort out the
other bugs I am CC'd on.
Yes, more formal QA might be a good thing, but this would be a great help
if we could get sufficient volunteers. If we can only manage part of the
bugs, then we are that much ahead -- much better than doing nothing till we
can implement a complicated scheme.
--
JRT
More information about the kde-quality
mailing list