jensclas wrote:
Under module design you have - install process - described in the read me file - I think you need to also have read me file - is included and covers 'required' details. eg title, version, author, license statement, install instructions, and credits. They also need to be 'readable' and reasonably correct in their use of language.

There are many modules that do not have a read me file at all - and there are tons of veriations in the content of a read me file. There is a need to set up some basic expectations of what would be in a read me file. Look at my article on read me files here - it is still in draft form but you will get the picture.

Other than that I think it looks good - but then I am not up to the rest of it - just looking out for newbies and readability.

off my soap box now!

Mithrandir wrote:
Looking better

What will be next step, once this specification is finished? Will you (with the Docs team, perhaps?) make a "Guide to Approval", explaining how to accomplish each task? I think that would be a tremendous guide.

You say yourselves in "S4 - Textsanitizer usage" that instructions on correct usage should be available and I think other tests could use the same (e.g. what constitues "Smarty compliant"?), so might as well make a section for each test, explaining
a) its purpose
b) how to make a module pass this test and
c) how the test is performed

I could also suggest a new category - C (for Code Standards) - where you take the P2 test about object orientation as well as general coding standards and core usage. I suggest that this new category has the following tests:
P2, A5 (Note that there are TWO A5's, I mean the one about permissions), A6, A7 and A11. An added use of core Notification (where applicable) could perhaps also be a new test?

Only one piece of feedback left now: B1 - it doesn't really matter to me, when I install a module, whether it has been in Beta and/or RC before being released. It is a nice reassurance for me to know that it will probably have fewer bugs than a module that was released without it, but since you ARE testing the module for bugs etc. I think it will not be fair for a module that passes ALL tests apart from this one to be noted "Did not pass this test"... when everything is working, the need for a Beta/RC is limited, I think.

It may serve to be an explanation for why the module fails other tests, and you should be able to conclude after performing the tests that it should have been released in beta/RC versions prior to final launch, but it should not be a test in itself.

Use what you can of this and I am of course available for working with you on the coding standard and core usage tests.

but perhaps should we not going too far, because of XOOPS V3. I'm waiting for v3 roadmap !!!!!

I could also suggest a new category - C (for Code Standards) - where you take the P2 test about object orientation as well as general coding standards and core usage. I suggest that this new category has the following tests:
P2, A5 (Note that there are TWO A5's, I mean the one about permissions), A6, A7 and A11. An added use of core Notification (where applicable) could perhaps also be a new test?

Mithrandir wrote:
I think the Excel document is excellent as a checklist for the tester to note the test results, but the test should result in a report, I think.

I imagine something along the lines of a document explaining each test, why is it tested (purpose), how is the test performed (procedure), what result is needed for it to pass (expectation) and how this is accomplished in example (explanation)

This document will tell developers how to program and document their module in order to pass the tests.

Now, when the tester has tested the module, using the spreadsheet to note the progress down, he or she takes the above document and adds sections to each test describing the results during the test (observation)

The report should end up with a conclusion on the tests - noting how the module performed in the tests and if you create a couple of categories for modules (such as Group A = All tests passed, Group B = Insufficient core usage, Group C = Insufficient documentation, but module is working and Group D = Unacceptable Bugs in module) which category this module is placed in and why. Recommendations like better testing procedures (if the bugs are so that they really should have been found in a beta/RC testing phase) could also go in this conclusion.

Quote:

but perhaps should we not going too far, because of XOOPS V3. I'm waiting for v3 roadmap !!!!!

Text sanitation is quite simple in XOOPS 2.0.x (as described in the Dev Wiki (although it may not be spelled out sufficiently WHEN one should use one over the other) and since it will not be changed very soon (see Rowd's report from XOOPSDEM) my opinion is that it should be included from the start and adapted for future versions of XOOPS.

I imagine that the code standards part will be expanded quite extensively with the development of this next major XOOPS version as we will put far more focus on people using the core correctly when we get that "clean sheet" foundation to work from.

MarcoFr wrote:
hervet suggested a QA module !!!!

we have to decide which rating model, we use. stars ? or Note ?

Rowd wrote:
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

I imagine something along the lines of a document explaining each test, why is it tested (purpose), how is the test performed (procedure), what result is needed for it to pass (expectation) and how this is accomplished in example (explanation)

This document will tell developers how to program and document their module in order to pass the tests.

Now, when the tester has tested the module, using the spreadsheet to note the progress down, he or she takes the above document and adds sections to each test describing the results during the test (observation)