What do you need before you start QA ?
Its Release Date and following text comes upon my eyes on the Postnuke mailinglist:
i'd suggest that everyone (especially our QA *smile*) grabs the current CVS snapshot for a brief test, especially regarding short urls and the new safehtml filter (to be configured in administration-settings).
So far .. some stuff any QAist needs before he jumps in checking a release:
1. Voice
Voice just means that found bugs are accepted and not discussed away because developers feel pissed about that great number of bugs that are found. If your ego can not live with harsh criticism, dont let someone QA your work, better do a direct rc to the public as soon as all bugs are closed.
2. No More Open Bugs
Sorry, fix all known bugs for the actual Version. No need to write more.
3. Documentation
Write a Documentation of the changes done and what they exactly should implement. A good thing is to write and stick to a rfc. So any one can test if thatpiece of code does exactly what you expect. If you dont have a rfc, you a re in charge to write this piece of information down for your QA. CVS Logs alone is NOT enough. Especially when the product is as big as Postnuke, a lot of written stuff has to be there and processes run silently with little information.
4. Time
Dont seta date for release before QA has researched and Dev Team has dgged through the bugs and the changes are reviewed by the qa and its sure that fixes are fixes
i'd suggest that everyone (especially our QA *smile*) grabs the current CVS snapshot for a brief test, especially regarding short urls and the new safehtml filter (to be configured in administration-settings).
So far .. some stuff any QAist needs before he jumps in checking a release:
1. Voice
Voice just means that found bugs are accepted and not discussed away because developers feel pissed about that great number of bugs that are found. If your ego can not live with harsh criticism, dont let someone QA your work, better do a direct rc to the public as soon as all bugs are closed.
2. No More Open Bugs
Sorry, fix all known bugs for the actual Version. No need to write more.
3. Documentation
Write a Documentation of the changes done and what they exactly should implement. A good thing is to write and stick to a rfc. So any one can test if thatpiece of code does exactly what you expect. If you dont have a rfc, you a re in charge to write this piece of information down for your QA. CVS Logs alone is NOT enough. Especially when the product is as big as Postnuke, a lot of written stuff has to be there and processes run silently with little information.
- all bugs in a tracker
- complete api docs
- brief descriptions of new features
- list of changed 3rd party components
4. Time
Dont seta date for release before QA has researched and Dev Team has dgged through the bugs and the changes are reviewed by the qa and its sure that fixes are fixes
Comments
No new comments allowed (anymore) on this post.