QA proposal for bugs

[Matt Rogers]

On Thursday 11 March 2004 14:43, James Richard Tyrer wrote:
> 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


Sorry, but I fail to understand why you're so hung up on verifying that bugs 
have actually been fixed. The biggest help anyone in the quality team could 
do at the moment with regard to bugs is to take an app in bugzilla, go 
through all the bugs, using the wiki page at  
http://wiki.kdenews.org/tiki-index.php?page=Bug+Triage as a guide. 

We have a massive amount of duplicated and/or unreproducable bugs. Also, crash 
bugs without valid stacktraces should be closed if you can't reproduce it.  

While I don't see a problem with your proposal, it would be more realistic at 
this point in time to do the above.

Matt