21
daddystu
Re: QA Smoketests
  • 2004/12/29 13:30

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Woah - you guys are making me feel realllly ignorant but I am in and not easy to get rid of
Thanks for putting me in the team, let's have a look at all this from a relative newbie perspective if you don't mind.

Writing the smoketests.
I really like the idea of using a well-known, simple module that we are all relatively happy with as a base from which we can write the smoketests.
Applying the test as we go to a single module would allow us all at whatever level of experise we have to reduce the chances for confusion.

So a few questions,
Do we agree that this is a good idea? If so, can we put together a candidate list for such a module?
If not, let's see why not and move on from there?
Remember I am just talking about writing the smoketests not applying them in full yet...

I also am very much in favour of keeping things lean at first so please let us stick with modules.

I second the minimising/standardising of the language / terminology we use, I work in English and Japanese every day and this is not something to be underestimated!!

22
daddystu
Re: QA Smoketests
  • 2004/12/29 14:17

  • daddystu

  • Just popping in

  • Posts: 100

  • Since: 2004/5/25


Need to see if I am on the right page at all here, I thought it might be useful to consider what criterion we would be looking at as we write these tests, something like this???

Please, please tell me if I am off-base, need to know now rather than later

Test - I INSTALLATION
Tester should consider

- if a zip package, when expanded, it expands 'clean' i.e. into the required folder not 'modules'>'moduleName' etc etc requiring the user to move the folders after expansion.

And the test itself would be...(kind of a la Mozilla)
# || test || what to do || what to check for

I.1 || prepare || vanilla XOOPS || no other modules
I.2 || Upload || upload zip || uploads OK
I.3 || expand || expand || expands 'clean'


Test - S SETUP
Tester should consider

- how much non-browser work is required (folder permissions, editing of php files or your specific information compared to being able to use modules>admin within XOOPS later)
- that the meaning of the terms is clear
- spelling/terminology is correct for that language

And the test itself would be...
# || test || what to do || what to check for

S.1 || prefs || go to XOOPS admin || prefs can be set here
S.2 || prefs || in XOOPS admin || meaning of prefs clear


This would have to be a loop I guess, we would need to set each preference, make sure it had the desired effect...looping through each setting then, would be part of the smoketest?

Like I say, let me know if I am on the wrong planet,
cheers

23
pisaldi
Re: QA Smoketests
  • 2004/12/30 22:19

  • pisaldi

  • Just popping in

  • Posts: 28

  • Since: 2004/8/5 1


Hi all !

I know to program in C and in Visual Basic...

But, I don't know to program in PHP nor Xoops... but, with my knowledge and a little help, I can understand the XOOPS Code...

So, what I think is the most important thing in a Module is a well documented Code, so everyone could understand the Code and learn to Code in XOOPS what means and helps to make XOOPS bigger...

In another hand, I think that is better to center our efforts, first in a group of Modules... for example, the News or the Bulletin or Calendar ones... and after that and having a beginning go to others...


My humble opinion....


Happy New Year !

24
Marco
Re: QA Smoketests
  • 2004/12/31 14:32

  • Marco

  • Home away from home

  • Posts: 1256

  • Since: 2004/3/15


just to inform you that I sliced yesterday this thread in several new ones (put all ideas that do not concern Smoketests in news threads grouped by suject)...

25
Dave_L
Re: QA Smoketests
  • 2004/12/31 16:19

  • Dave_L

  • XOOPS is my life!

  • Posts: 2277

  • Since: 2003/11/7


THanks, Marco, that was helpful.

26
m0nty
Re: QA Smoketests
  • 2005/1/6 21:16

  • m0nty

  • XOOPS is my life!

  • Posts: 3337

  • Since: 2003/10/24


interesting and rather a lot to take in initially, but some good points raised..

i think we should start small tho initially till we all become comfortable with what we are meant to be doing. a series of smoke tests etc on the smaller less functional modules would be a good start before moving onto the more complex and multi functional modules..

i'll have a further read of everything over the next few days and see if i can add anything, but it all looks good so far :)

27
danielh2o
Re: QA Smoketests
  • 2005/1/6 23:05

  • danielh2o

  • Just popping in

  • Posts: 47

  • Since: 2004/10/19


Glad to join QA Team there are tons of post already... :-O

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?



Quote:

Dave_L wrote:
I think the first, or one of the first items on the agenda is to devise a format/template for module smoketests.

Ackbarr and Herko have suggested that the Mozilla Smoketests may provide a good starting point.

I've also outlined some ideas in this Roadmap.

One way to start is to draft an example smoketest for one of the most common modules. And then we can discuss it, and make some refinements.

28
jensclas
Re: QA Smoketests

Quote:

danielh2o wrote:
Glad to join QA Team there are tons of post already... :-O

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



Hi there - please add
documentation
-module description
-installation files

see my other post for suggested criteria. in this thread

Cheers

29
jorgebarrero
Re: QA Smoketests

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.

30
jorgebarrero
Re: QA Smoketests

Herko

I aggree onthis Isue. I have been loking for a place where to look as a model to start developing a module. It is a high demanding task.

Noce Idea to set up a "Standard" and a "model" to look at and compare. Even to start with.

If I make a module I would like:

1. Start the right way. (not copy someone's module)
2. Have a "approved skeleton"
3. Have the codding standards (proably recomended tools)
4. Have some examples avialable
5. Have some where to copy and paste "standard" routines for not reinventing the wheel
6. Have a GUI Standard
7. Have the "smoketests" Standards so I can test before realeasing.

In the future would be nice to have a "Module Generator" or somting like this.

humble opinion

Login

Who's Online

200 user(s) are online (105 user(s) are browsing Support Forums)


Members: 0


Guests: 200


more...

Donat-O-Meter

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

Latest GitHub Commits