Hands off from QA: Moodle and Linus’s Law (part 3)

As of 1 May, QA tests 98 are open, 46 on hold, 8 failed and 430 passed. My “grand total” completed tickets is 5. This post is a reflection of what I have learnt and actually done differently since writing Moodle QA Part 2.

Testing Locally

Testing locally is a way of avoiding the qa.moodle.net server hourly reset and getting more tests done quicker. However, there was an unexpected learning curve required for Moodle admin. The set-up required for local testing was:

  • Download & install the dev stand-alone Local Server (with Moodle)
  • Create a QA Test course
  • Create a list of users (or download my list – 1 Teacher & 5 Students)
  • Set passwords for each user. NB: Change the password rules for easier rules.
  • Install screengrab tool, Skitch. This is extremely fast tool as you can drag and drop the screengrabs directly onto the Moodle tracker.
  • A bit of time getting used to the Moodle.Net tracker. For example advanced search for open issues using syntax:
project = MDLQA AND parent = MDLQA-12911 AND assignee is EMPTY ORDER BY key

What really helped were the Moodle Administration videos by HRDNZ Moodle Partner on YouTube. Most were about 10 minutes long with clear explanations.

Daily Testing

What to QA

Of the 98 open tickets, 78 are unassigned tests. These are the tickets that need to be tested.

My strategy was to find a component with multiple items e.g. Workshop Activity. Typically the IDs were in a series, and the tests on a continuum.

Many tests are beyond what I can test. Some require a server open to the internet. Some require specific third party technologies. I can only let someone else do these – there’s at least 20 other testers.

The next crack at testing should be faster and easier still. Further down the rabbit hole I go. That ends this series of getting started with Moodle QA (until Moodle 3.8).

Leave a reply

Your email adress will not be published. Required fields are marked*