diff --git a/docs/apis/access.md b/docs/apis/access.md index 262b1ae3f3..6a52b7b88e 100644 --- a/docs/apis/access.md +++ b/docs/apis/access.md @@ -32,7 +32,6 @@ User access is calculated from the combination of roles which are assigned to ea All users that did not log-in yet automatically get the default role defined in `$CFG->notloggedinroleid`, it is not possible to assign any other role to this non-existent user id. There is one special guest user account that is used when user logs in using the guest login button or when guest autologin is enabled. Again you can not assign any roles to the guest account directly, this account gets the `$CFG->guestroleid` automatically. All other authenticated users get the default user role specified in `$CFG->defaultuserroleid` and in the frontpage context the role specified in `$CFG->defaultfrontpageroleid`. - +A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise. + +**End sync period**
+During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release. + +**Personal projects**
+Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints. + +**Code freeze**
+A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for [QA testing](/general/development/process/testing/qa). + +**QA, bug fixing, continuous integration**
+A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release. + +**Release candidate**
+A point prior to the full release where a candidate is made public for wider testing. ## New feature development diff --git a/general/development/process/integration-review.md b/general/development/process/integration-review.md index 99c0e1fb28..1dd232765f 100644 --- a/general/development/process/integration-review.md +++ b/general/development/process/integration-review.md @@ -91,12 +91,12 @@ The integrators adhere to the following schedule: (links here should convert the All the flow of issues to current integration is automatically controlled by the [Manage queues on normal job](https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/) that keeps the current queue fed with issues, moves important ones and priotitises long awaiting issues. Issues are picked in strict integration order. -- Monday to Thursday until [12:00 (UTC+8)](http://time.unitarium.com/utc/4): Integration and [Testing](https://docs.moodle.org/dev/Testing_of_integrated_issues#The_testing_process) happen. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction. +- Monday to Thursday until [12:00 (UTC+8)](http://time.unitarium.com/utc/4): Integration and [Testing](/general/development/process/testing/integrated-issues#the-testing-process) happen. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction. - Thursday after 12:00 (UTC+8): Integrators duties during this time are to monitor, facilitate and 'problem solve' the testing process. - Friday: Testing should be completed before (the sooner the better) 12:00 (UTC+8) at which time remaining testing failures will be reverted/rewritten and reopened. The release process follows. - Friday after [12:00 (UTC+8)](http://time.unitarium.com/utc/4): Should be kept free from integration. Integration systems are maintained during this time. -Note that under the strict schedule above, it is specially important **to be as responsive as possible**, both when the issue is being integrated and when [testing](https://docs.moodle.org/dev/Testing_of_integrated_issues#Expectation_from_tester). Any significant delay by any of the actors involved will result in the issue being moved out from current integration. +Note that under the strict schedule above, it is specially important **to be as responsive as possible**, both when the issue is being integrated and when [testing](/general/development/process/testing/integrated-issues#expectation-from-tester). Any significant delay by any of the actors involved will result in the issue being moved out from current integration. ### During continuous integration/Freeze/QA period @@ -112,8 +112,8 @@ Throughout: So, basically, once under continuous integration, we do organize work as follows: - Continuous officially begins. Everybody is on integration. Until end of on-sync period. -- Monday: Integration and [testing](https://docs.moodle.org/dev/Testing_of_integrated_issues#Differences_in_test_process_during_continuous_integration_periods) happens. -- Tuesday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to [achieve 100% 'Test Passed'](https://docs.moodle.org/dev/Testing_of_integrated_issues#Differences_in_test_process_during_continuous_integration_periods) and stop integrating any untested changes until a master release is produced. +- Monday: Integration and [testing](/general/development/process/testing/integrated-issues#differences-in-test-process-during-continuous-integration-periods) happens. +- Tuesday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to [achieve 100% 'Test Passed'](/general/development/process/testing/integrated-issues#differences-in-test-process-during-continuous-integration-periods) and stop integrating any untested changes until a master release is produced. - Wednesday: [Assuming a master release has been rolled] Integration and testing continues - Thursday: Integration and testing continues - Friday: Integration happens until [12:00 (UTC+8)](http://time.unitarium.com/utc/4), afterwards we try to achieve 100% 'Test Passed' and stop integrating any untested changes until a master release is produced. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction. diff --git a/general/development/process/testing.md b/general/development/process/testing.md new file mode 100644 index 0000000000..bd414f92e3 --- /dev/null +++ b/general/development/process/testing.md @@ -0,0 +1,100 @@ +--- +title: Testing +description: All the information related to testing during the Moodle development. +tags: + - Processes + - Core development + - Testing + - Quality assurance +--- + +This page is the top level page regarding all testing activities around the Moodle project. Testing is essential to make sure that developed code does what it is meant to do, without causing new problems. + +## Manual testing + +### Code testing + +Code is tested as part of reviewing at some key parts of the [Moodle development process](/general/development/process). + +- `Development`. The developer of some code should test their own work on a wide variety of environments for correctness and performance +- `Peer review`. Developers often test each others work early in the development process +- `Integration review`. The integration team tests code weekly while they are evaluating suitability for integration into Moodle. + +:::info More info + +We recommend that you follow the [[Testing instructions guide]] to help you write clear manual testing instructions. + +::: + +### Integration functional testing + +Moodle has a dedicated team of testers who perform most of the manual testing for integration issues. Developers submitting patches **should always cover the patch with unit tests and/or Behat behavioural tests**. + +:::info More info + +We recommend that you follow the [Testing of integrated issues guide](/general/development/process/testing/integrated-issues) to get a better understanding of how testing integrated issues works. + +::: + +### QA testing + +Once all major features for a new Moodle release have landed, Moodle performs a Quality Assurance test cycle. This test cycle is typically performed by volunteers from the Moodle community who systematically test each available feature to ensure that it still works as intended. This process typically lasts 4-6 weeks and happens once per Major release. + +:::info More info + +We recommend that you follow the [QA testing guide](/general/development/process/testing/qa) to know more about the Quality Assurance test cycle. + +::: + +For major theme changes, additional manual tests may be run. + +## Automated testing + +### Unit tests + +PHPUnit tests are supported as part of the code from Moodle 2.3 onwards. These are automated tests of very low-level code functionality that a developer should write as part of any new code. + +:::info More info + +We recommend that you follow [[PHPUnit integration]] to help you run and write unit tests. + +::: + +### Acceptance tests + +Moodle uses a framework called Behat to automatically test the user-interface. Tests can be written for each plugin, and for Moodle core. + +- To run the existing tests, read [[Running acceptance test]]. You really need to do this first. +- To write new tests, read [[Writing acceptance tests]]. +- To define new steps that can you used when writing tests, see [[Writing new acceptance test step definitions]]. + +:::tip +Because Behat tests work through the Moodle user interface, they are a bit slow. Therefore, you should probably also use PHPUnit to test the detailed edge cases in your code. +::: + +### Continuous integration testing + +As soon as code is added to the integration repository, the continuous integration server tests the new code for: + +- Coding guidelines +- PHPUnit tests +- SimpleTest unit tests on older versions of Moodle +- Detect unresolved merge conflicts +- Compare databases upgraded from previous versions +- Check the version.php is correct + +A failure here notifies the integrators that the build has failed. + +### Regression testing + +Every day, an automated build in a test server runs a large number of tests concerning key functions of Moodle, to make sure that everything still works and that some new fix in Moodle hasn't caused problems elsewhere. + +These tests must pass completely before a new release can be made. + +- [[Unit tests]] using the PHPUnit framework +- [[Acceptance testing]] using the Behat framework +- Performance testing using JMeter. + +:::note +Moodle uses a sponsored version of [BrowserStack](https://www.browserstack.com/) for testing on multiple browsers. +::: diff --git a/general/development/process/testing/integrated-issues.md b/general/development/process/testing/integrated-issues.md new file mode 100644 index 0000000000..46509b624d --- /dev/null +++ b/general/development/process/testing/integrated-issues.md @@ -0,0 +1,109 @@ +--- +title: Testing of integrated issues +description: All the information related to the integration review process during the Moodle development. +tags: + - Processes + - Core development + - Testing + - Quality assurance +--- + +Testing is an important part of the [Moodle development process](/general/development/process). +Depending on the integration period (normal or continuous) testing can take place at different times. +Your first priority as a tester should be to finish testing on the day they have been assigned. You should update the testing status so that the testing status is clear. + +## The testing process + +:::note + +1. Tests are allocated during the week by the Integration Team. Tests are usually performed by a dedicated team of test engineers but sometimes they may be assigned to HQ developers too. +2. HQ developers should check mail or search tracker to see which issues are assigned to them for testing. + +::: + +1. Pull latest integration from [git://git.moodle.org/integration.git](git://git.moodle.org/integration.git) +2. Test issue by following the **Testing instructions** +3. Select `Pass test` or `Fail test` as appropriate, adding a short description of what was tested if not obvious +4. If you find you cannot finish testing a particular issue, click `Stop testing` and let the Integration team know about it. +5. When a test is failed the assignee is usually contacted and asked to respond or provide a fix. If the patch is provided late and there is no time to find a new tester then the issue will be reopened. +6. Once the fail fix is integrated, it goes back to **complete re-testing**. +7. It's the responsibility of the tester to test the issue again, unless the patch is from tester. If the tester provides fix patch then test will be re-assigned. +changed. +8. The tester who passes the issue will be set as the tester for the issue. + +:::info Failing a test session + +For test sessions, if you encounter a failure, please fail the issue add a comment on the issue itself. If everything's good, add a comment in the session and complete the session. You may also comment on the issue and say that testing passes on your part. + +::: + +## Expectation from developer and peer-reviewer + +Testing instructions are clear, concise, complete, and accurate. Where possible they should be easy to perform. Please follow the [[Testing instructions guide]] recommendations. + +## Expectations of the Integration team + +- Tests should be allocated when the issue is integrated. +- The integration team may need to help/re-assign tests if developers are having problems. + +## Expectation from tester + +- Testing **must happen always against up to date integration.git repository** (unless testing instructions include some exceptional git operation). More specifically, testing **must not happen against development branches** for a number of reasons (based on old core stuff, missing interdependencies with other issues or changes performed along the integration process, upgrade problems...). +- If tester is not available for testing, this should be raised ASAP. +- Testers should try to finish testing as early as possible as they are assigned, so when tests fail, the issue assignee has as much time as possible to resolve it. +- When a test fails, or new (related) regression found then fail test. +- If tester is not sure of results or need explanation on testing instructions, then tester can either fail test with comments, or contact the assignee individually to raise the problem. +- Testers should let the integration team know ASAP if they are facing any problems, need help or may not be able to complete their allocated tests +- For any reason (big test, not enough time, not started testing yet), if a test is dragged to next day then the tester should leave comment on tracker, updating the status of testing and adding the expected time needed to finish testing. +- When a test is passed, it is recommended to add some extra information that confirms that all works as expected. This could be a browser screenshot, terminal output... +- **All UI tests should be tested on currently supported themes**. + +### Checking tests assigned to you + +1. Log in to [Tracker](https://tracker.moodle.org/). +2. Visit [Issues waiting to be tested](https://tracker.moodle.org/issues/?filter=11801&jql=project%20%3D%20MDL%20AND%20Tester%20%3D%20currentUser()%20AND%20status%20%3D%20%22Waiting%20for%20testing%22) page. + +## Differences in test process during continuous integration periods + +During [continuous integration](/general/development/process/integration-review#during-continuous-integrationfreezeqa-period) the schedule is changed to allow faster iteration and for bug fixes to be applied more reapidly than the usual weekly cycle. The goal during this period is ... +goal during this period is to release a new version of master multiple times per week. We try to keep the process more flexible during this time in order that developers who have less pressing issues than others can take the load off those concentrating on big fixes. It works best if we work together to help each other out. + +:::warning +Priority is given to testing issues to ensure we can release regularly +::: + +## 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 + git clone git://git.moodle.org/integration.git +``` + +as the very first command. + +:::tip + +Alternatively, you can also use [Moodle Development Kit (MDK)](https://docs.moodle.org/dev/Moodle_Development_kit), and add the option `--integration` to install a Moodle instance based on integration.git. + +::: + +### Changing theme to another one + +Ensure you have following setting in the config (it allows you to change the theme in the URL). + +```php + $CFG->allowthemechangeonurl = true; +``` + +For changing to a theme named "yay" add **?theme=yay** to the url. + +## Notes + +- If the issue requires an Oracle or MSSQL installation for testing, and you don't have one, [docker](/docs/gettingstarted/quickstart#docker) may help you. +- Any update should be added as a comment on the tracker issue being tested. +- If testers pass or fail an issue by mistake, then please request the integration team to reopen it for testing. +- 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. diff --git a/general/development/process/testing/qa.md b/general/development/process/testing/qa.md new file mode 100644 index 0000000000..a8c1914f25 --- /dev/null +++ b/general/development/process/testing/qa.md @@ -0,0 +1,258 @@ +--- +title: QA testing +description: All the information related to the Qualify Assurance tests during the Moodle development. +tags: + - Processes + - Core development + - Testing + - Quality assurance +--- + +**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 ensure that it works in the current version of the Moodle code. These tests are repeated in a series of cycles, around 4 - 6 weeks before each major release, once all major features have landed. + +## Getting involved + +Would you like to help with QA testing? If so, please make sure you have created an account in the [Moodle tracker](/general/development/tracker) and you're subscribed to the [Testing and QA forum](https://moodle.org/mod/forum/view.php?id=56) in order to receive QA testing news updates. + +## Running tests + +1. Go to the [Moodle QA testing dashboard](https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11454) and choose a test from the list of current QA cycle open issues. When viewing a test, if you wish, you can click the 'Assign to me' link on the right, so that nobody else chooses the same test to run. (If you then find you are unable to run the test, you can click the Assign button and set the assignee as 'Unassigned'.) Please note: + - Only assign an issue to yourself which no one else is testing (Assignee = Unassigned). + - Only assign one issue at a time unless you plan to test a number of related issues within the next 24 hours. In other words, don't assign several issues to yourself then do nothing for several days. ;-) + - The label `test_server_required` indicates issues that can't be tested on the QA testing site. The label `credentials_required` indicates that credentials such as an OAuth 2 service client ID and secret are required. +2. Using either the [Moodle QA Testing Site](https://qa.moodledemo.net/) or your own test site running the latest Moodle 4.0dev (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. +3. Please *attach screenshots of the steps where you verify or check something*. +4. If it makes sense, please test using the currently supported themes, Boost and Classic. +5. Choose an appropriate workflow action: + - `Pass` - Test runs perfectly. Add comment such as feedback about a new feature, browsers used for testing (if applicable; example: "This test passes on Q&A site with Teacher role using Boost theme"), or simply "This test passes - yippee!" + - `Fail` - Something doesn't work, or you obtain debugging messages. Add comment describing the step that doesn't work. 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 comment explaining why. + +:::info Out of date tests + +If you notice that the test description is out-of-date, add a comment mentioning that it needs updating. Alternatively, if you'd like to help with updating the test yourself, see below. + +::: + +## Any questions? + +If there is anything you are unsure of, such as whether to mark a test as failed, or you have any other questions, please ask in one of the following places: + +- [Moodle QA Telegram chat room](https://t.me/moodleqa) - To join the room for the first time, please use the [Moodle QA Telegram invite link](https://t.me/+cXneE_ZeZ_A4ODRk). +- [Testing and QA forum](https://moodle.org/mod/forum/view.php?id=56) + +## Moodle QA Testing Site + +The [Moodle QA Testing Site](https://qa.moodledemo.net/) is updated daily at around 13:00 UTC with the latest bug fixes to enable you to re-run QA tests. + +Credentials for Teacher and student accounts are provided on the login page. + +:::info E-mail on the QA site + +No e-mail will be sent from the QA server. Tests involving e-mail **cannot** be performed on the Moodle QA Testing Site. + +If you perform any test which tries to send e-mail, a debugging message will be displayed. + +::: + +:::tip Admin access + +If you require admin access to the Moodle QA Testing Site for running certain tests, please ask in the [Moodle QA Telegram chat room](https://t.me/moodleqa) or the [Testing and QA forum](https://moodle.org/mod/forum/view.php?id=56) for someone to send you the account credentials via private message. + +::: + +## Failed tests + +So you ran a test and it failed? Congratulations on finding a bug! Please do the following. + +1. Click the `Fail` button at the top of the page. +2. Add a comment to the QA test stating that there was a problem and that you will report it as a Moodle bug. +3. Note the MDLQA number; it will be something like {tracker MDLQA-448}. +4. Try searching for whether the bug has been reported previously, and if not create a new issue for it (as described in [Tracker introduction](/general/development/tracker)). +5. In the new Moodle (MDL) issue select 'Link' from the 'More actions' dropdown menu. +Linking to the QA issue in the tracker +6. 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. +Adding details for a link to the QA issue +7. Give the issue the label `mdlqa`. +8. (Optional) Add yourself as a watcher to the MDL issue so that you receive email notification when the issue is fixed. +9. When the MDL issue is fixed, hopefully within a day or two, the QA test can be reset and can then be run again. + +## Resetting tests + +:::info Note for integrators + +After integrating a fix: + +1. `Reset` the MDLQA test, adding a comment. +2. Remove the `mdlqa` label from the MDL issue. +3. If the issue doesn't have 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. + +## Fixing existing bugs + +At the beginning of the QA cycle, all bugs identified (both new and existing) are investigated promptly and hopefully fixed. + +When we are close to the scheduled release date (1-2 weeks prior), developers must focus on fixing new bugs (which affect the upcoming release version) only. + +Thus, at this point in the QA cycle, any bugs which also affect existing versions of Moodle are labelled `qa_identified` (and the label `mdlqa` removed) for investigation after the release. + +## Testing tips + +When entering text into a form, try things like: + +- `&` (ampersand), `>` (greater than) or `<` (less than) +- `0` (the single digit 0) +- `'` (single quote) +- special characters +- very long strings +- different languages, such as a RTL language + +:::tip For example: + +``` +x < 1 && x > 0 +``` + +``` +Fergal.O'Brien@example.com +``` + +``` +café +``` + +``` +囲碁 +``` + +::: + +## New QA tests required + +:::info Note for developers + +If an issue fix cannot be covered by automated tests, + +1. Add the label `qa_test_required` to the issue. +2. Add a comment explaining why it can't be covered by automated tests and suggesting which steps of the testing instructions should be included in a QA test e.g. steps 6-10 or all steps. + +::: + +QA tests will then be written and included in the next QA cycle. For issues with long testing instructions, several QA tests will be written to cover the issue. If appropriate, activities etc. will be set up on the [Moodle QA Testing Site](https://qa.moodledemo.net/) to enable the issue to be easily tested in future. + +### New features, and improvements + +Where a new features or improvements would benefit from exploratory testing, you should: + +1. Add the label `qa_test_required` to the issue. +2. Add a comment mentioning that exploratory testing is required. + +:::note + +When the next QA cycle is prepared, any issue with the `qa_test_required` label will be reviewed and appropriate **exploratory QA tests** written, before the label is then removed. + +::: + +## Updating tests + +QA tests may become out-of-date due to User Interface changes, feature changes, and new features. If you would like to help with updating tests, you'll need to be a member of the test writers group in the Tracker. Please contact Helen about being added. + +To update a QA test original: + +1. Search for the test in {tracker MDLQA-1}. +2. Edit the test description. + +:::note + +If a test in the current QA cycle is marked as failed because it is out-of-date, the description should be updated (as well as the test original) before resetting the test. If the test in the current QA cycle is marked as passed, then only the test original needs to be updated. + +::: + +## Writing new tests + +Would you like to help with writing new QA tests? To write new QA tests you will need to be a member of the test writers group in the Tracker. Please contact Helen about being added. + +QA tests are needed for any features which can't be tested with automated testing, such as connecting to an external system, drag and drop functionality or a CLI script. Also if it requires a person to detect if something is 'correct' vs. present/absent on the page. + +In addition, new features can benefit from exploratory testing by community volunteers. + +To create a new QA test: + +1. If appropriate, do a quick search of {tracker MDLQA-1} to check if there is an existing test which can be updated. +2. If not, in {tracker MDLQA-1} from the More menu select 'Create sub-task'. +3. Enter a summary such as 'A teacher can ...'. +4. Select 'Original' as affected version and select appropriate components. +5. In the description field add the test steps (usually between 3 and 10), similar to the issue's [testing instructions](https://docs.moodle.org/dev/Testing_instructions_guide), starting with 'Log in as a teacher...' or similar. It's a good idea to try doing the steps yourself as you write the test. +6. Start some steps with 'Verify that ...' or similar. +7. Click the Create button. +8. Go to the MDL issue and create a ‘has a QA test’ link to the new QA test, adding a comment “This feature is now covered by the QA test MDLQA....”. + +:::note + +- Add the label `new` +- For tests which can’t be run on the QA testing site, such as ones where you need to check an email, label `test_server_required`. +- For OAuth 2 tests and any other tests which require a client ID or secret to be entered, label `credentials_required`. +- For issues which specifically mention in the testing instructions to test in different browsers, use the phrase: + +> Test in as many browsers as possible and mention in a comment which ones you’ve used. + +- For an exploratory test, begin the test description with: + +> This is an exploratory test of a new feature or improvement, so please feel free to try anything you like and not just the test steps! + +- For a test requiring admin access which can be run on the QA site, add: + +> This test requires admin access. If you would like to use the [QA testing site|https://qa.moodledemo.net/] for running it, please see the [QA testing guide|https://docs.moodle.org/dev/QA_testing] for details of how to request admin access. Begin just after the hourly reset to give yourself plenty of time to complete the test! + +::: + +## Feedback + +Feedback on all aspects of our QA testing process is welcome. + +:::tip + +If you have any questions or comments, please post in the [Testing and QA forum](https://moodle.org/mod/forum/view.php?id=56). + +::: + +## Previous QA cycles + +Comments on tests from previous QA cycles: + +- [Moodle 2.0 QA Cycle 1](https://tracker.moodle.org/browse/MDLQA-150) +- [Moodle 2.0 QA Cycle 2](https://tracker.moodle.org/browse/MDLQA-328) +- [Moodle 2.0.2 QA](https://tracker.moodle.org/browse/MDLQA-540) +- [Moodle 2.1 QA](https://tracker.moodle.org/browse/MDLQA-944) +- [Moodle 2.2 QA](https://tracker.moodle.org/browse/MDLQA-1190) +- [Moodle 2.3 QA](https://tracker.moodle.org/browse/MDLQA-1814) +- [Moodle 2.4 QA](https://tracker.moodle.org/browse/MDLQA-4602) +- [Moodle 2.5 QA](https://tracker.moodle.org/browse/MDLQA-5267) +- [Moodle 2.6 QA](https://tracker.moodle.org/browse/MDLQA-5740) +- [Moodle 2.7 QA](https://tracker.moodle.org/browse/MDLQA-6693) +- [Moodle 2.8 QA](https://tracker.moodle.org/browse/MDLQA-7170) +- [Moodle 2.9 QA](https://tracker.moodle.org/browse/MDLQA-7660) +- [Moodle 3.0 QA](https://tracker.moodle.org/browse/MDLQA-8205) +- [Moodle 3.1 QA](https://tracker.moodle.org/browse/MDLQA-9267) +- [Moodle 3.2 QA](https://tracker.moodle.org/browse/MDLQA-9827) +- [Moodle 3.3 QA](https://tracker.moodle.org/browse/MDLQA-10403) +- [Moodle 3.4 QA](https://tracker.moodle.org/browse/MDLQA-10999) +- [Moodle 3.5 QA](https://tracker.moodle.org/browse/MDLQA-11698) +- [Moodle 3.6 QA](https://tracker.moodle.org/browse/MDLQA-12282) +- [Moodle 3.7 QA](https://tracker.moodle.org/browse/MDLQA-12911) +- [Moodle 3.8 QA](https://tracker.moodle.org/browse/MDLQA-13517) +- [Moodle 3.9 QA](https://tracker.moodle.org/browse/MDLQA-14131) +- [Moodle 3.10 QA](https://tracker.moodle.org/browse/MDLQA-14813) +- [Moodle 3.11 QA](https://tracker.moodle.org/browse/MDLQA-15457) +- [Moodle 4.0 QA](https://tracker.moodle.org/browse/MDLQA-16122) + +## See also + +- [QA testing dashboard](https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11454) +- [Testing credits](https://docs.moodle.org/dev/Testing_credits) +- [Useful tips for QA testing](https://moodle.org/mod/forum/discuss.php?d=351302) diff --git a/migratedPages.js b/migratedPages.js index 6b6536751f..20c22d137e 100644 --- a/migratedPages.js +++ b/migratedPages.js @@ -1,6 +1,7 @@ const path = require('path'); const obsoleteDocs = [ + "MDLQA-features", "Setting_up_Eclipse", "Setting_up_Netbeans", ]; @@ -21,7 +22,10 @@ const migratedDocs = { "Overview": "/general/community/intro.md", "Peer_reviewing": "/general/development/process/peer-review.md", "Process": "/general/development/process.md", + "QA_testing": "/general/development/process/testing/qa.md", "Roadmap": "/general/community/roadmap.md", + "Testing": "/general/development/process/testing.md", + "Testing_of_integrated_issues": "/general/development/process/testing/integrated-issues.md", "Tracker_intro": "/general/development/tracker.md", "Tracker_tips": "/general/development/tracker/tips.md", }; diff --git a/sidebars/general.js b/sidebars/general.js index ed79c389e3..87c84c2b71 100644 --- a/sidebars/general.js +++ b/sidebars/general.js @@ -33,6 +33,26 @@ const sidebars = { items: [ 'development/process/peer-review', 'development/process/integration-review', + { + label: 'Testing', + type: 'category', + items: [ + { + label: 'Integrated issues', + type: 'doc', + id: 'development/process/testing/integrated-issues', + }, + { + label: 'Quality Assurance (QA)', + type: 'doc', + id: 'development/process/testing/qa', + }, + ], + link: { + type: 'doc', + id: 'development/process/testing', + }, + } ], link: { type: 'doc', diff --git a/src/css/custom.css b/src/css/custom.css index 595710d0a0..f312658ed5 100644 --- a/src/css/custom.css +++ b/src/css/custom.css @@ -36,3 +36,7 @@ [data-theme='dark'] .docusaurus-highlight-code-line { background-color: rgba(0, 0, 0, 0.3); } + +.docusaurus-hidden { + display: none; +}