651
Marco
Just to precise our goal
  • 2004/12/30 19:37

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


"- goal: to support the QA process, whose goal is to achieve and maintain a high quality standard for XOOPS modules, so that the modules are useable, maintainable, and suitable for continued development"

Setting the standards
shoawing the way
providing the tools

positive force and not negative force
insiring and teaching others, to flatten the learning curve

what else ?



652
Marco
Re: Certification ? Scalable or One Shot ?
  • 2004/12/30 19:36

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


In Dave's roadmap are some responses !
http://dave-l.com/grafix/downloads/xoops/qa_roadmap.php

- levels
- A (full certification): all mandatory and recommended standards met
- B (limited certification): all mandatory standards met
- C (restricted certification): not all mandatory standards met
- S (special certification): for handling special cases, such as temporary withdrawal of a module due to serious bugs or security exploits
- U (uncertified): not known which standards are met
- certifier (person or group performing certification)
- indicated in posted certification level, e.g. A1, A2, B3
- 1: QA team
- 2: qualified third party (recognized by QA team as qualified to perform certification)
- 3: other third party

are you all ok ?



653
Marco
Certification ? Scalable or One Shot ?
  • 2004/12/30 19:32

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


Should we consider to offer :
- ex: 3 ranks of certication (like hotels stars *,**,*** e.g. classification system),
- or only a binary certification (YES/NO) ?

cf "I agree that you just don't want all coders to quit of the QA is too strict and coems out as arrogant"

just to talk about !
marco



654
Marco
Common criteria
  • 2004/12/30 19:24

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


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 ?



655
Marco
Re: Establishing the baseline.
  • 2004/12/30 19:03

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


Hello

Should we consider than if a module is QA certified, it will be portable (because certified module does follow XOOPS standards) in any upcoming XOOPS version, so that our testing platform should always be the last XOOPS version ?

But how about LAMP platform (think about php5 effects)?

marco



656
Marco
Just to define our scope : modules and/or themes ?
  • 2004/12/30 18:53

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


Hy,

In response of QA Smoketests thread, here are ideas and common answers about our questions...


Quote:

are you just focusing on module development? How about theme?

- there are more useless modules out there than there are bad themes
- there's no reason not to include themes as well. I someone would like...
- mosts projects that fails are unfocused. So I suggest that we concentrate on modules and leave themes for later on or for someone else
- themes and modules sort of run hand and hand iin my mind so realy the impact on themes should be part of the QA

decision ?


Quote:

Is system module in our scope

- I don't find it usefull to go through the current system module parts, as we know they are not up to shape and they will be changed in the future

decision ? NO --->I think everybody is ok wih this !



let's talk about this !



657
Marco
Re: WARNING: File ....mainfile.php is writeable by the server.
  • 2004/12/28 16:45

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


use smartftp, at www.smartftp.com
free, and powerfull
marco



658
Marco
Re: QA Smoketests
  • 2004/12/27 17:44

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


Quote:

However, I don't find it useful to go through the current System module parts, as we know they are not up to shape and they will be changed in the future. If not by the core developers, then by disgruntled third-party developers

I agree, this will reduce a little bit our scope ! Was just to precise our scope...
What about themes...as discuss before ?

How about choosing modules to test first in early beginning of our work ? Using xoops.org wfdownloads statistics could be a great idea,no ?

marco



659
Marco
Re: QA Roadmap
  • 2004/12/27 17:33

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


Quote:

Herko Coomans wrote:
I've also added Falke and marcoFR to the QA Team. Welcome guys
Herko

thanks, nice to be with you !
no women ?



660
Marco
Re: QA Smoketests
  • 2004/12/27 17:28

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


Hy,

First, I'm glad to be with you !

Mith or Herko, could you first confirm that Core Modules Concept will be left and precise when ? In next upcoming 2.1 ?

If so, is System module in our scope ?

What about testing plateform, as told irmtfan ? Which rule shall we set ?
Always to test modules under the 2 last version of LAMP plateform ?

I use some steps as you probably do when I test/debug modules. It's a quick contribution to our smoketest methodology :
Light explanation :
0/ Validate xoops_version file
1a/ Test module installation
1b/ Test module upgrade (refresh in admin)
1c/ Test update script (i.e no data are lost)
2/ Play with module under debug mode
- Test admin configuration
- Test use of smarty variables
- Test bloc configuration
3/ Validate translation directories
it's a quick list, I know, but it's the "methodology" I usually use... I'm shure you make other/better tests too !

Is module ergonomy in our scope ?

About module conflicts ?
Shall we use a standard configuration, e.g. news+newbb+wfsection+etc...
it relies on existence of core module in future XOOPS packages...

just my 2cnt
marco




TopTop
« 1 ... 63 64 65 (66) 67 68 69 ... 71 »



Login

Who's Online

54 user(s) are online (31 user(s) are browsing Support Forums)


Members: 0


Guests: 54


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Aug 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits