Development:Testing: Difference between revisions
David Mudrak (talk | contribs) m (Added information about installing a local test site) |
|||
(8 intermediate revisions by 2 users not shown) | |||
Line 6: | Line 6: | ||
==The testing process== | ==The testing process== | ||
# | # On Tuesdays, go through the 'Ready for testing' pull requests - browse to http://tracker.moodle.org/browse/PULL then click the issue link and then the 'Ready for testing' link (only available after integration reviews on Monday) | ||
# 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 | # Choose a pull request which you'd like to test, click 'Start testing' and add yourself as QA tester | ||
# 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 (see below on how to set up one) | |||
# 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 you find you cannot finish testing a particular pull request, click 'Stop testing' so that the pull request is again listed as ready for testing. | |||
The production maintainer (or someone delegated to the task) will close / reopen all MDL issues corresponding to passed / failed pull requests once the weekly packages are available. | |||
==Installing a local test site from the integration repository== | |||
Moodle uses two [[Git]] repositories for its source code. Their names are moodle.git and integration.git and they live at http://git.moodle.org. All submitted patches that were accepted during the integration review go to the integration.git first. Testers use integration.git as the source of the code to test. Patches that survive testing are then promoted to moodle.git and become the part of the official Moodle weekly build. | |||
To obtain the code from the integration.git repository, follow the instructions at [[Git for Administrators]] page. But instead of cloning from git://github.com/moodle/moodle.git, use | |||
git clone git://git.moodle.org/integration.git | |||
as the very first command. | |||
==Notes== | ==Notes== | ||
* For issues which require an Oracle | * 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 | * 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) | * 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 | * 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. | |||
[[Category:Quality Assurance]] | [[Category:Quality Assurance]] |
Latest revision as of 01:12, 22 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
- On Tuesdays, go through the 'Ready for testing' pull requests - browse to http://tracker.moodle.org/browse/PULL then click the issue link and then the 'Ready for testing' link (only available after integration reviews on Monday)
- Choose a pull request which you'd like to test, click 'Start testing' and add yourself as QA tester
- 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 (see below on how to set up one)
- Select 'Pass test' or 'Fail test' as appropriate, adding a short description of what was tested if not obvious
If you find you cannot finish testing a particular pull request, click 'Stop testing' so that the pull request is again listed as ready for testing.
The production maintainer (or someone delegated to the task) will close / reopen all MDL issues corresponding to passed / failed pull requests once the weekly packages are available.
Installing a local test site from the integration repository
Moodle uses two Git repositories for its source code. Their names are moodle.git and integration.git and they live at http://git.moodle.org. All submitted patches that were accepted during the integration review go to the integration.git first. Testers use integration.git as the source of the code to test. Patches that survive testing are then promoted to moodle.git and become the part of the official Moodle weekly build.
To obtain the code from the integration.git repository, follow the instructions at Git for Administrators page. But instead of cloning from git://github.com/moodle/moodle.git, use
git clone git://git.moodle.org/integration.git
as the very first command.
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.