Package-specific test case and critical path test case project: drafts for review

[Adam Williamson]

On Mon, 2011-01-03 at 10:52 -0500, James Laska wrote:

> Agreed ... I think it makes sense to keep Category:Test_Cases as just a
> container for sub-categories if possible.  Mainly for the reasons you
> note around *trying* to keep content organized.

OK. I think I actually went ahead and changed this in the current
version, I'll go back and double check.

> My
> question (I guess I already re-stated above) was whether you consider
> the terms "core" and "extended" as a designation of test case priority?

Yes. The terms themselves aren't hugely important, sure, it's more
expressing the concept of priorities, but I kind of conceived it in
terms of the importance of the functionality being tested.

> Outside of the terminology, I have some concerns whether this is within
> the scope of the initial project, or something we want to leave as a
> phase#2 effort.  We definitely need to think about it as non-critpath
> tests will come in, I just hope we don't spend all our collective energy
> on defining non-critpath tests and then we are still exposed to a lack
> of test documentation for the critpath.

My thinking here is that one of the typical workflows for creating test
cases will be 'let's create a set of test cases for package X'. Say the
maintainer of package X decides to contribute some test cases. I suspect
it's quite unlikely they'll restrict themselves strictly to critical
path functionality in all cases; so we should already have the
groundwork for non-critical-path test cases laid out.

> > possibly. I was meaning those bits to be read simply as a potential
> > illustration of programmatic use of the categories to illustrate why
> > consistent categorization is important, but if you think it's confusing,
> > we could take it out.
> 
> No strong opinions here.  I thought I learned somewhere that one should
> avoid future leading statements when documenting process.  I could have
> sworn that was in the Fedora doc guide ... but I could be making it up.

I'd agree with that - again the idea was to illustrate a design concept
('this is designed this way in order to enable this kind of programmatic
usage') rather than to prescribe a particular form of programmatic usage
on the part of particular tools. I tried to re-write it to be less
specific in a later draft that's up now, is it better?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net