[QA] To clone or not to clone ( a bug report ) that's the question...

"Jóhann B. Guðmundsson" johannbg at hi.is
Fri Jan 23 12:51:17 UTC 2009


Kevin Kofler wrote:
> "Jóhann B. Guðmundsson" wrote:
>   
>> Please dont mix testers with triagers these are 2 separated teams.
>>     
>
> But if one of the teams is not expected to clone bugs, then neither is the
> other. :-) So this policy is equally relevant to both teams.
>
>   
There are exceptions to every rule :)

But indeed in most cases the same applies and from my perspective
more to testers than to triagers.

Testers need to report as correctly and add correct attachments and so
on from the start.

If that goal is accomplished it should really take load off both
triagers and maintainers.

But to reach that goal we need documentation, train testers.

We need test cases and above all what the maintainer wants on a reports 
against his component.

Unfortunately we have little to nothing on the above :(

I and others are trying to address that issue.

> And there are activities which are really both testing and triaging, like
> retesting if a bug still applies, at least at KDE upstream this is
> something the triagers do. Is there already a policy who's responsible for
> such activity? If not, I'd suggest you go talking to the triagers about it.
> (Right now, I don't see any such retesting going on, so I get the (possibly
> mistaken) impression that each team is expecting the other to do it. ;-) )
>
>   
Retesting from my perspective should be in the hand of A) the reporter 
and B) Testers

If maintainers need testing send a mail to the test-list.

If you need test cases or help setting up or anything else from QA
open a ticket in the new fedora-qa trac instance on fedorahosted.

>> It would be good if you could spend some time of your writing energy
>> writing testing/ test cases for your components and how you would like
>> testers to report to components that you maintain.
>>     
>
> If I start writing test cases for KDE, I'll never finish... Canned test
> plans just don't work for huge GUI apps with many features, unless you have
> a specific feature you want to test (e.g. to verify whether a given bug is
> fixed).
>
>   
I disagree I think this is doable, we need to come up with template for 
the most common
nominators in the gui app ( open new save help etc..  ) then just add 
test cases for those
that are not.
>> And so far I have not published anything without it being approved
>> first  either on a QA meeting
>> or by the maintainer giving his blessing on testing/test cases that it's
>> like he wants it.
>>     
>
> The problem is that the way to handle bug reports is something which affects
> packagers and triagers much more than it affects testers. You just file the
> bug(s), the packagers and triagers will have to deal with them. So a tester
> meeting is a bad place to decide on such a policy.
>
>   
Again if the report does this properly from start the need of triaging 
should be to minimum.
> In addition, a statement like "There will be no time "pressure" matter since
> the guideline has already been written and made so debates can be stuck in
> infinite loop until the storage space on the mail server fills up.." makes
> you sound totalitarian. Maybe I should give you the benefit of the doubt
> and assume something got lost in translation?
>   
My good man your not asking the right question and you don't get answers 
to question you don't ask.

You should be asking me why do I feel that the -devel list is an
inefficient way to use for communication/intellect discussion 
invention's and finally a decision making.

I'll try to be more subtle this time and explain in more detail what I 
mean..

I feel that way because a lot of topics here are..

A) The same ones over and over again and finally when things have settle 
down we make a release and
     since there was no solution found or that solution/decision not 
properly documented and put on a page on the wiki
     the whole thing starts again.

B) A lot of topic start as A but end up as Y or Z so the original topic 
got lost and the answer to
     that topic still remains unresolved..
     ( that's why you saw me being so harsh I sensed it start heading in 
that direction )

C)  A lot of great ideas ( and not so great ) come up on this list are 
we documenting them
      For example are we putting them on think tank page on the wiki? 
      So they can be revisited when time or manpower are in place to 
work on some of those ideas
      I believe we are not doing it and I feel that they just get lost 
and buried in the paper flood.

D) Allot of the discussion that happens here are without people 
proposing alternative solution a different approach
     to the task at hand but instead you see people start taking sides 
and the debate continues and the task at stays stale.
     ( And in this case Mark did come with an alternative answer to the 
questions being asked and so did you later in the game )

D) A lot of topic here do no belong on this list and should redirected 
to their appropriate mailing lists
     Redirect end users topic to their list, test related topics to the 
test list etc..

And the answer to all this boils down to things being as they are 
because we allowed them to be.

Instead of redirect traffic to they appropriate mailing list...
Instead of taking notes when good solution come..
Instead of when the same topic reappear the person that brought up that 
topic is redirect to the place that holds the final solution that was 
found..
.....
....

So my question is..

Are we doing any stats on the traffic on this mailing list as in how 
many threads are constructive and how many reach final decision vs
how many end up in "my side is better than yours" and traffic that 
should be else where etc.. ?

So the conclusion that I have come to regarding this mailing list can be 
proven wrong...

JBG


-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 372 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090123/d5d9a16f/attachment.vcf>


More information about the fedora-devel-list mailing list