Testing of integrated issues: Difference between revisions
From MoodleDocs
Line 9: | Line 9: | ||
# Test the new 2.0 features/fixes on the [http://qa.moodle.net/ Moodle QA Testing Site] and 1.9 fixes on a local site | # Test the new 2.0 features/fixes on the [http://qa.moodle.net/ Moodle QA Testing Site] and 1.9 fixes on a local site | ||
# Select 'Pass test' or 'Fail test' as appropriate, adding a short description of what was tested if not obvious | # Select 'Pass test' or 'Fail test' as appropriate, adding a short description of what was tested if not obvious | ||
# If the test passes, close the corresponding MDL issue, add a fix version of the next unreleased version e.g. 2.0.2 (keeping any sprint version and only deleting any backlog version) and yourself as QA assignee | # If the test passes, close the corresponding MDL issue, add a fix version of the next unreleased version e.g. 2.0.2 (keeping any sprint version and only deleting any backlog version) and yourself as QA assignee | ||
# If the test fails the assignee has to deal with the issue - accept fix from the reported or revert the code and reject the issue | # If the test fails the assignee has to deal with the issue - accept fix from the reported or revert the code and reject the issue | ||
# If the issue is rejected, the assignee should reopen the MDL issue | # If the issue is rejected, the assignee should reopen the MDL issue |
Revision as of 22:16, 18 January 2011
Note: This page is for analysing and developing our weekly testing of code added to the integration server. It is a work-in-progress. Comments or suggestions are welcome! Please use the page comments.
Testing is an important part of the Moodle development process.
The testing process
- Go through the 'Ready for testing' pull requests
- Test the new 2.0 features/fixes on the Moodle QA Testing Site and 1.9 fixes on a local site
- Select 'Pass test' or 'Fail test' as appropriate, adding a short description of what was tested if not obvious
- If the test passes, close the corresponding MDL issue, add a fix version of the next unreleased version e.g. 2.0.2 (keeping any sprint version and only deleting any backlog version) and yourself as QA assignee
- If the test fails the assignee has to deal with the issue - accept fix from the reported or revert the code and reject the issue
- If the issue is rejected, the assignee should reopen the MDL issue
Notes
- For issues which require an Oracle installation for testing, Petr, Eloy and Apu have one
- The MDL issue should be used for general comments about the issue, rather than PULL issue, as less people are watching PULL issues
- If testers pass or fail a pull request by mistake, there is currently no way for them to revert their change (please message Petr to get it fixed)
- Testers should not be involved in the bugfixing or review process