Mithrandir wrote:
Quote:

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

Sure, but is that really what you need?

Don't you just need to be able to put in various fields and specify whether a test is passed or failed? I'd suggest using a module like Formulize for this.

Quote:

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

It is also my opinion:

Getting these things up and running should get you started:
1. A checklist of tests
2. An explanatory document, explaining each test and how to perform it
3. A reporting tool - like Formulize - for documenting the 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.

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?