Here are some ideas taken from our famous "QA Smoketests" post.

"Certified modules should respect these criteria" :

- fit to XOOPS standard features : notifcation, theme managment, templates, installation
- well documented
- respect of naming convention( variables, functions calls,etc.). What about coding standards ?
- commented code ?
- secure code ?
- used XOOPS API to it's fully expand ? what is fully ?
- fast queries, server memory impact, server load
- packaging
- directory structure
- W3C compliant ? XHTML 1.0 ? browser compatibility ? CSS? --> use of QA Standard Certified Themes ?
- easy install / uninstall
- langage definition standard respect
- readme, licence files, changelogs, credits, support website reference, bug reporting link, feedback link
- smarty compliant
- module conflict ? If a module follow all the above, there will be no module conflicts, no ?

what else ?

Hi All


Quote:

We need to be really clear on the cireteria for this - as it can be very subjective. In deciding if something is well documented it needs to:

Meet the purpose of - informing and instructing

Meet the needs of an audience - the user who may be a total newbie, and someone who isn't native to the language in which it is written.

Meet a speficic style/form and language- so perhaps we could suggest a list of common things we expect to see in the content of documentation, eg.
What this module is intended for,
how to install it,
how to set it up,
how to use it,
troubleshooting installation,
contact the writer.

In order to make it readable the simpler the vocabulary the better. For the benefit of easy translation to other languages documentation need to avoid coloquial phrases and metaphors that do not accurately translate into other languages and cuultures.

Just some ideas for consideration in setting standards - can't help wih lots of others but with documentation I am right in my comfort zone!

Cheers

I've said other times.... but the documentation is very important...

And we should tell, which should be the main language in which to document the modules !!!

It will be obviously english... but some developers know to program, but their written english isn't very good....

copy paste of danielh2o's posts


------Smoketests format/template, can we start with this...

1 installation

1.1 download
-validate url (as proposed by module developer)
-validate user (if url outside xoops.org, should provide a valid common user for QA download?)
-validate zip file download successful

1.2 preparations
-validate zip file decompression
-validate numbers of decompressed folders / files (e.g. php/sql/language files, as proposed by developer)
-validate README file (or install procedures) existence is a must!
-validate module versions

1.3 install
-validate module files upload successful with required access right
-validate installation procedures (or module upgrade) successful
-validate module existence (ie. admin page)

2 module usage
2.1 admin setting
-block
-group
-preference

2.2 base / configuration data
...
2.3 user functions
...

Should we have a list of 'mandatory' QA items first?

-------------------- another post

Below QA items zoom into my head! Perhaps, some easy for them, some not... depends on module's complexity.

Documentation
-module description (acceptable brief / detail enough)
-installation procedures
-user manual
-technical manual; data dictionary, design specification
-change logs / modification history
-known problems and troubleshoots
-to-do list / future directions

Common practice
-naming standard
-coding standard
-database standard

Quality considerations
-security
-performance
-cache usage / memory leakage
-degree of Object Oriented practice
-reusablity
-scalability
-post support after launch

copy paste of jorgebarrero's post


---------
I really think that ergonomy is an issue.

Is not only about if a module works. It is also about if it does what it promises.

hum,

herko/Dave_L spoke about "the Mozilla Smoketests "

some of you about "Macintosh User Guide Interface is a good example of how creating a common set of expected behaviors helped finnal users"

+ "QA should have a way to make translations and language in general consistent.
Is very confusing if you use two different words in separate module for the same purpose.
Something like a Bank of terms shoul be needed " --> good translation with common words....