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