Hello all
The Moodle Testing group has been active for just over 2 weeks. I thought I'd give a quick update.
There are now more than 15 registered testers in the group. While this is definitely a good sign, there hasn't been all that much activity as evidenced by the few number of bugs moving to closed status. One person, Nicolas Martignoni, is clearly leading the charge on testing bugs. His is, without question, the biggest contributor so far. Thanks Nicolas!
Hopefully you've noticed the changes in Tracker to accommodate testing. The new field "QA Assignee" appears on most input screens. The easiest way to get to it on existing bugs is by using the "edit" button on the left hand navigation panel. The public filter "1.7 Resolved" shows bugs ready to test. Visit it regularly to get feel what's being fixed - and what needs testing! I see a fair amount of variation in the way all contributors are using Tracker. How about some discussion among the testers to sort these out? Communication will certainly help get everyone on the same page.
The procedure for updating bugs in Tracker is simple. Make sure you read the section "Testing bugs" here. If there are questions, or you think there should be more instructions available, don't be afraid to post or email me direct at michael@moodle.com.
Thanks for contributing to the test effort, and let's see if we can knock off a pile of bugs in the coming week.
I've been using my tester status mainly to resolve issues. I would like further clarification when it is acceptable to resolve and close an issue at one time. If it is a duplicate for example, can we just close it?
Most of the bugs I have been resolving aren't 1.7 bugs (although I have reported a few) simply because I don't have my own 1.7 installation and frankly don't have the time at the moment (getting ready to defend my PhD in November) to be putting into the detailed testing most issues deserve before being marked as closed.
Most of the bugs I have been resolving aren't 1.7 bugs (although I have reported a few) simply because I don't have my own 1.7 installation and frankly don't have the time at the moment (getting ready to defend my PhD in November) to be putting into the detailed testing most issues deserve before being marked as closed.
I would like further clarification when it is acceptable to resolve and close an issue at one time.
I also have a few questions about resolving and closing bugs:
1. What is recommended for bugs filed by a developer as a record of a change that was made against head? For example MDL-6418, MDL-6478, or MDL-6715.
2. There are several old bugs in tracker that have been addressed as part of the natural evolution of Moodle. For example MDL-483, MDL-258, or MDL-259. Should we just close bugs like these as we encounter them?
I also have a few questions about resolving and closing bugs:
1. What is recommended for bugs filed by a developer as a record of a change that was made against head? For example MDL-6418, MDL-6478, or MDL-6715.
2. There are several old bugs in tracker that have been addressed as part of the natural evolution of Moodle. For example MDL-483, MDL-258, or MDL-259. Should we just close bugs like these as we encounter them?
I think you have found an interesting bug-tracker filter bug. Why aren't the middle bug ids linkified?
As the filer and fixer of MDL-6418, I think you should severly reprimand the person who created such a useless bug report
What was I on about? I think all you can do is mark it closed and move on.
As the filer and fixer of MDL-6418, I think you should severly reprimand the person who created such a useless bug report
For duplicates, create a link to the original bug - an "issue links" box is created in Tracker making it easy to see the connection to other bugs. You can then 'close' the bug with a resolution code of 'duplicate'. There is no need to 'resolve' the bug, then 'close' it if you are confident that further testing would be a waste of time. If you're unsure, leave the status 'resolved'. Be sure to comment.
For bugs that have been previously fixed or have been addressed by the natural growth process, the same method as above can be applied except a resolution code of 'cannot reproduce' or 'not a bug' should be used. Be sure to comment with your rationale for closing the bug.
If you're uncertain about the bug ask questions by adding a comment to the bug. I don't see people doing this nearly enough. The creator and assignee will be notified of comment and should help the tester by providing clarification/insight/whatever.
For bugs that have been previously fixed or have been addressed by the natural growth process, the same method as above can be applied except a resolution code of 'cannot reproduce' or 'not a bug' should be used. Be sure to comment with your rationale for closing the bug.
If you're uncertain about the bug ask questions by adding a comment to the bug. I don't see people doing this nearly enough. The creator and assignee will be notified of comment and should help the tester by providing clarification/insight/whatever.
