I think the work done so far is great, but it's starting to move away from designing smoketests and towards standards. I'm working on Action item #2, writing a document describing the QA standards. Your work here seems to be crossing over into what I'm doing, which is probably not the best use of your valuable time
I suggest leaving the Section 1 - Module Design section of the smoketests until the standards document is finished.
Then for Section 2, "Module Acceptance", you really should start making detailed descriptions of how you will carryout your tests... e.g. for "A6 Comment - Is this module using XOOPS comment system? test posting" you need to explain exactly what to do so you can be certain that the testing is consistent (all testers need to follow the exact same actions for the results to be valid).
For example:
1. Set permissions to allow anonymous users to post comments.
2. Post a comment as an anonymous user.
3. Reply to your comment as an anonymous user.
4. Set permissions to disallow anonymous users to post comments.
5. Attempt to post a comment as an anonymous user..... etc....
It's boring work writing it all out, but I think it's the only way to guarantee that everyone performs the same test. It will also mean you can give a precise report of why a module didn't pass QA - "testing failed at A6-2: was unable to post as anonymous user"...
I also think there should be a more defined separation between Section 1, which ONLY looks at code, and Section 2, which should ONLY look at how the module functions. So I'd move Smarty/template compliance to Section 1.
I agree with Mith's comment about moving P2 Object Oriented into Section 1, as it's a coding standard and is included in the standards doc I'm working on
I also think P1 sql queries test belongs in Section 3 Debug, as you just need to turn on MySQL/Blocks Debug to check that, you don't need to install a sql counter.
I'm not quite sure what you mean with P3 - Ergonomy, or how you intend to test it...?
As Mith said, as a checklist of QA tests it's looking really good. The next step is describing each test in more detail, so testers can provide detailed feedback about the test results... though that's just my opinion, of course
Rowd