Quote:

Work on this action will start this week-end.
Livrable : Excel Spredsheet
Any volonteer will be welcomed !

come on, guy's....!
marco

Ok, lets get into action, what needs to be done?

hy everyone

Sorry to be late,
jorgebarrero, I apologize not to have answered to you quickly.
But this last month was a great busy XOOPS month, with News 1.3 Debug party and improvments, and with other translation/debug works.

Here is a draft version of our smoketests works.

Please give any comments, add on, feeedback about this one.

It's a first draft and should be considered as this.
hope to hear some echos from you (!)
marco

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!

thanks for you comment
i need to improve this first attempt :
- give more details on what a dev or QA tester should do exactly
- work on security aspects more in details

Do you see any item that I missed ?

Hy,

here is the last version,
it has to be improved in many parts. I have still to work on :
- giving more details on what a dev or QA tester should do exactly
- on security aspects more in details
- giving more details for install /readme /upgrade &co file's content.

What do you think about this ?
marco

let me know when you have done this bit

Quote:

Then i'll look it over - the rest is for others...cheers

Just looked over the document and I think it is a good start.

Some elements should be specified a bit further to give a better understanding of what it takes to comply.

Also some elements are not always applicable (not all modules should have a "include" folder, and only a few - if any - should have a "cache" folder)
Module preferences should also only be a criteria if applicable.

What is the difference between A12 and B5? Also, could you specify a bit more, what is meant with D5 - if this module need an extra class, an extra directory should be there?

Specific elements:
A10 - Module should work with another database... why? XOOPS only supports MySQL, so we can hardly expect modules to work with other databases (or did I misunderstand this test?)

Apart from that, I think it is good - after a spellcheck and correction

Keep up the good work.

thanks to Myth and JasonMR for your comments
here is a new version

Please help us to improve this 2nd draft !

marco

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.