Quality Assurance tests look at the functionality of Moodle from a user's point of view.
Real users systematically try each feature in Moodle and test that it works in the current version of the Moodle code. These tests are repeated in series of cycles, usually just before major releases.
Would you like to help with QA testing? Before our next QA cycle starts you are welcome to try things out on the Moodle QA Testing site and post in the Testing and QA forum about any issues you come across, or any questions you have. If you come across any bugs (obvious problems), please report them in the Moodle tracker.
Note: The Moodle 2.7 QA cycle is due to start on 14th April 2014 (source: Roadmap).
- Select a test from the list of QA tests. If you wish, you can click the 'Assign to me' button, so that nobody else chooses the same test to run. (If you then find you are unable to run the test, you can assign the issue to 'Nobody'.)
- Using either the Moodle QA Testing Site or your own test site running the latest Moodle 2.6 beta (available from Git on the integration/master branch git://git.moodle.org/integration.git) with debugging set to developer, perform each of the steps listed in the test
- Note that the test_server_required label has been added to the MDLQA issues that can not be tested using only the Moodle QA Testing Site and requires an additional or external server.
- Choose an appropriate workflow action:
- Pass - Test runs perfectly :)
- Fail - Something doesn't work, or you obtain debugging messages. See below for actions to take. If in doubt whether to pass a test, give it a fail and add a comment describing your doubts.
- Obsolete - Test is no longer relevant in the current Moodle version.
- Add a comment (e.g. "This test passes - yippee!") to confirm that the test wasn't accidentally passed without being run.
Please note: If you are behind a firewall you do not control or content filtering system, it may interfere with the use of the Moodle QA site. It is advisable that testing is completed where such complications are not in place.
If you notice that the test description is out-of-date, add Helen as a watcher (username tsala) then add a comment suggesting how it can be updated.
Note: Always use the latest version of Moodle 2.6 beta for testing or the Moodle QA Testing Site. Contact Helen if you would like admin access to the Moodle QA Testing Site.
So you ran a test and it failed? Congratulations on finding a bug! Please do the following.
- Click the Fail button at the top of the page.
- Add a comment to the QA test stating that there was a problem and that you will report it as a Moodle bug.
- Note the MDLQA number; it will be something like MDLQA-448.
- Try searching for whether the bug has been reported previously, and if not create a new issue for it (as described in Tracker introduction).
- In the new Moodle (MDL) issue select 'Link' from the 'More actions' dropdown menu.
- Link to the QA test by selecting 'blocks' as the link type, entering the MDLQA number that you noted earlier, and optionally adding a comment.
- Give the issue the label 'mdlqa'.
- (Optional) Add yourself as a watcher to the MDL issue so that you receive email notification when the issue is fixed.
- When the MDL issue is fixed, hopefully within a day or two, the QA test can be reset and can then be run again.
Note for testers:
The Moodle QA Testing Site is updated daily at 00:00 UTC with the latest bug fixes to enable you to re-run QA tests.
Note for integrators:
After integrating a fix,
1. Reset the MDLQA test, adding the following comment (or similar):
Thanks for running this QA test. The bug causing it to fail has now been fixed, so the test can be reset and run again. Please note that if you are using http://qa.moodle.net for testing, you will need to wait for the site to be updated at 00:00 UTC in order to test the bug fix.
2. Remove the 'mdlqa' label from the MDL issue.
3. If the issue has not own testing instructions, pass it with message "Will be tested by MDLQA-XXXX"
The tester will then receive email notification that the bug is fixed and will hopefully decide to run the test again soon.
The role of core developers in creating tests
When a developer adds functionality to Moodle, they should also do the following.
- Write user documentation in the dev docs about the new feature (this should happen as part of the normal development process). Ask someone to proof read this documentation.
- Add a feature to the release notes. This feature should include a link to the appropriate Tracker issue, which will contain testing instructions. The feature should also include a link to the user documentation for the feature.
The QA tests will be written by a test writer based on the documentation and release notes written by the developer.
Writing new tests
Would you like to help with writing new QA tests? If so, you'll need to be a member of the test writers group in the Tracker. Please contact Helen about being added.
To create a new QA test:
- Choose an issue from the list of qa_test_required labelled issues
- Create a sub-task of MDLQA-1
- Select Master copy as affected version
- Select appropriate components including at least one of the following: User, Student, Teacher, Administrator
- Leave the assignee as automatic (nobody)
- Write the test (usually between 3 and 10 steps)
- Add a comment to the MDL issue mentioning the new QA test and remove the qa_test_required label.
New tests will be included in the next QA cycle.
Feedback on all aspects of our QA testing process is welcome. If you have any questions or comments, please post in the Testing and QA forum in Using Moodle.
Comments on tests from previous QA cycles: