[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-promo
Subject:    Re: [kde-promo] Re: KDE Quality Team implementation
From:       Tom Chance <tomchance () gmx ! net>
Date:       2004-01-03 13:35:55
Message-ID: 200401031335.55778.tomchance () gmx ! net
[Download RAW message or body]

On Saturday 03 January 2004 13:23, Datschge wrote:
> > Suse implemented a nice thing for their last beta phase, maybe we can
> > learn from that. They basically implemented a database with test
> > scenarios as plain text descriptions, e.g.
> > 
> > application: kmail
> > test: accessing huge mailboxes with >1000 messages with imap
> > description: ....
> > status:
> > 
> > In the status field people can enter
> > - wether this works
> > - a comment field (e.g. to describe, if only a part of the test could be
> > executed)
> > - if it not works, which bug report is accociated
> > 
> > As a tester this was a great thing, because you have a structured way to
> > go through things. This way you also can maintain a list of features
> > which would be showstoppers if they wouldn't work.
> > 
> > Basically this could be integrated into bugs.kde.org... if one did the
> > work ;-)
> 
> You mean as a new kind of severity?

If a new severity level "testcase" were added, such that normal queries never 
found any test cases, and quality teams could quickly bring up a list of test 
cases for their application, that would be quite a good idea. It could also 
be a handy reference point during the development cycle (as well as in the 
release cycle).

That would provide a very basic, unreliable but indicative QA mechanism.

Tom
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on \
or temporarily stop your subscription.


[prev in list] [next in list] [prev in thread] [next in thread]