Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Testing of integrated issues: Difference between revisions

From MoodleDocs
(→‎The testing process: closing MDL issues)
(→‎The testing process: testing site)
Line 7: Line 7:


# Go through the 'Ready for testing' pull requests
# Go through the 'Ready for testing' pull requests
# 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] or a local site and 1.9 fixes on a local site, updated from the integration server
# 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



Revision as of 15:08, 16 March 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

  1. Go through the 'Ready for testing' pull requests
  2. Test the new 2.0 features/fixes on the Moodle QA Testing Site or a local site and 1.9 fixes on a local site, updated from the integration server
  3. Select 'Pass test' or 'Fail test' as appropriate, adding a short description of what was tested if not obvious

The production maintainer will close (in bulk) all MDL issues for to pull requests which pass testing.

Notes

  • For issues which require an Oracle and MSSQL installations 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
  • Pull process related comments should be done in the PULL issue
  • 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
  • If an issue cannot be fixed within a sprint and has to be reopened, the fix for sprint version should be removed and an appropriate backlog version set.