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

James Laska jlaska at
Tue Jan 4 18:35:55 UTC 2011

On Tue, 2011-01-04 at 17:57 +0000, Adam Williamson wrote:
> 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.

Gotcha, thanks.

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

I see.  Yeah, we certainly need to be prepared for tests created outside
the initial scope.

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

That looks good.  Your pages are looking really good IMO, thanks for the
time+energy you've invested.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : 

More information about the test mailing list