On Tue, 2011-01-04 at 17:57 +-0000, Adam Williamson wrote:
+AD4 On Mon, 2011-01-03 at 10:52 -0500, James Laska wrote:
+AD4
+AD4 +AD4 Agreed ... I think it makes sense to keep Category:Test+AF8-Cases as just a
+AD4 +AD4 container for sub-categories if possible. Mainly for the reasons you
+AD4 +AD4 note around +ACo-trying+ACo to keep content organized.
+AD4
+AD4 OK. I think I actually went ahead and changed this in the current
+AD4 version, I'll go back and double check.
+AD4
+AD4 +AD4 My
+AD4 +AD4 question (I guess I already re-stated above) was whether you consider
+AD4 +AD4 the terms +ACI-core+ACI and +ACI-extended+ACI as a designation of test case priority?
+AD4
+AD4 Yes. The terms themselves aren't hugely important, sure, it's more
+AD4 expressing the concept of priorities, but I kind of conceived it in
+AD4 terms of the importance of the functionality being tested.
Gotcha, thanks.
+AD4 +AD4 Outside of the terminology, I have some concerns whether this is within
+AD4 +AD4 the scope of the initial project, or something we want to leave as a
+AD4 +AD4 phase+ACM-2 effort. We definitely need to think about it as non-critpath
+AD4 +AD4 tests will come in, I just hope we don't spend all our collective energy
+AD4 +AD4 on defining non-critpath tests and then we are still exposed to a lack
+AD4 +AD4 of test documentation for the critpath.
+AD4
+AD4 My thinking here is that one of the typical workflows for creating test
+AD4 cases will be 'let's create a set of test cases for package X'. Say the
+AD4 maintainer of package X decides to contribute some test cases. I suspect
+AD4 it's quite unlikely they'll restrict themselves strictly to critical
+AD4 path functionality in all cases+ADs so we should already have the
+AD4 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.
+AD4 +AD4 +AD4 possibly. I was meaning those bits to be read simply as a potential
+AD4 +AD4 +AD4 illustration of programmatic use of the categories to illustrate why
+AD4 +AD4 +AD4 consistent categorization is important, but if you think it's confusing,
+AD4 +AD4 +AD4 we could take it out.
+AD4 +AD4
+AD4 +AD4 No strong opinions here. I thought I learned somewhere that one should
+AD4 +AD4 avoid future leading statements when documenting process. I could have
+AD4 +AD4 sworn that was in the Fedora doc guide ... but I could be making it up.
+AD4
+AD4 I'd agree with that - again the idea was to illustrate a design concept
+AD4 ('this is designed this way in order to enable this kind of programmatic
+AD4 usage') rather than to prescribe a particular form of programmatic usage
+AD4 on the part of particular tools. I tried to re-write it to be less
+AD4 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.
Thanks,
James
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
