View Single Post
Posts: 53 | Thanked: 49 times | Joined on Jun 2007
#55
Originally Posted by VDVsx View Post
Here is a summary of the possible improvements: http://wiki.maemo.org/Extras-testing...A_Improvements

This was not discussed yet with the maemo.org tema, and is far from final, feel free to suggest some improvements.
I made some improvements on the wiki page, but I would have some major suggestion which I didn't want to impose by overwriting the wiki page: If there is a checklist - use it!

First on the page there should be a listing showing the overall checklist status for a package. Below is a mockup:
(-2/5 shows how many tester are needed "smiling" for that task to be finished. In this case I assumed that smiley is +1 and unhappy is -3.)

Tasks Done [4/8]
...
3. [1/1 ] Announced features available.
4. [-2/5 ] Working provided features.
* FAIL: When exporting file the program crashes (see bug: http://url/456)
5. [1/1 ] No performance problems.
...

Tester would have a list of tasks which are not finished with voting interface. By pressing a [+] on top of the list all tasks would be shown so tester is able to give additional confirming or denying vote. The tester would see her previous vote and should be able to change it. Additionally the tester should be able to write a comment for each testing task - this would be required for unhappy face. Additionally a tester should be able to give general comment.

...
Testing
[+] show all tasks
4. [tested ok |v] Working provided features.
[Concentrated on importing functionality ]
7. [not tested |v] No known security risks.
...

When all tasks would be done the application would go automatically to extras if guarantee time would be over and there wouldn't be any unhappy faces. If there would be unhappy face, some über-tester should decide if the issue is a blocker or not.

If a package which was accepted before would be sent to the testing queue for bugfix/update release, it would have all tasks as done expect for the features and some randomly selected task. If application description would be the same as before, announced features task would be done. This way the testing would concentrate on functionality, and acceptance on other areas would be still checked from time to time.

I would remove the word karma from the testing - people have karma due to their activities, applications have acceptance testing tasks. Like in this case, all tasks should be finished, not that there is 10 smileys for "no performance problems" and it's all ok.
 

The Following 3 Users Say Thank You to VRe For This Useful Post: