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

Kevin Kofler kevin.kofler at chello.at
Fri Jan 23 03:38:14 UTC 2009


"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.

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. ;-) )

> 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).

> 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.

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?

        Kevin Kofler




More information about the devel mailing list