User Acceptance Testing
Acceptance Test Strategy - Draft UAT Plan
User Acceptance Testing:
- this is the responsibility of the Moodle Service Team
- the testing will be performed in the Moodle Test Environment
- the testing will take place in the testers' normal working area
- this is currently scheduled to start on 5th January 2016 - this will be reviewed on completion of Design Review expected 30th October 2016
- feedback will be managed via the project's JIRA test log held under TEL025
Project meetings will continue throughout the testing stage
The Acceptance Sign-off Review milestone is currently scheduled for 12th February 2016 - this will be reviewed on completion of Design Review expected 30th October 2016
1.Roles & Responsibilities
Role | Responsibilities | Name |
Project Manager | · Communication with the Business Assurance Coordinator to agree format and scope of UAT · Ensure acceptance criteria are agreed prior to commencing UAT | Karen Stirling |
Business Analyst | · Assist Business Assurance Coordinator with the creation of a detailed test plan · Review scripts/cases and scenarios for accuracy, completeness and sequencing. · Confirm test data is correct.
| Stephannie Hay |
Technical Architect | · Validation of UAT environment | Neil Grant |
Business Assurance Coordinator | · Ensure that a detailed test scripts/cases, scenarios and instructions are available for test users prior to the start of testing · Ensure that issues identified during UAT are logged in the Test Log · Ensure testing takes place within agreed timeframes | Stephannie Hay |
Testers | · Execute test scripts/cases · Document test results | Stephanie Hay Mark Findlay Ross Ward Wesley Kerr Crystal Webster |
Test Participants
Testing participants include representative from all areas involved in the solution. Testers and their specific areas of focus are identified in the table below:
Name | Area Represented | Testing Area of Responsibility |
Stephanie Kerr / Mark Findlay / Wesley Kerr / Ross Ward | Moodle Service Team | All areas |
Crystal Webster | IS Helpline | All areas with exception of Admin |
Test Scenarios and Acceptance Criteria
Test Case 01:Web Based Interface | Pass/Fail |
Test Description: Access to web interface via EASE Authentication | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
1.1 | 1.2, 1.3 | MUST | Log into application URL using EASE. User logs in without any error messages and is taken to the appropriate screen. |
|
|
1.2 | 1.1 | MUST | User searches for and selects a course to create. User can start to free type/paste an ID into the search box and a list of course to select from appears, user can then select the relevant course. |
|
|
1.3 | 1.1 | MUST | User searches for and selects a course to create, the cancels out of the process.. User can start to free type/paste an ID into the search box and a list of course to select from appears, user can then select the relevant course then unselect the course/cancel process as required. |
|
|
Test Case 02: Creation of Courses | Pass/Fail |
Test Description: Create a course in Moodle | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
2.1 | 2.1, 2.4, 2.5 | MUST | User searches for, selects and then clicks create within application. Within Moodle the course should be created with the relevant information added into the correct fields. The course is then visible within Moodle and is linked to the correct course category. It can be viewed through the course category tree or searched for. |
|
|
| 2.2 | 2.1, 2.4, 2.5 | MUST | Test the scenario where a course is delivered twice a year:
Within Moodle two distinct courses will be created with the relevant course information in the correct fields. The courses are then visible within Moodle and are linked to the correct course category. They can be viewed through the course category tree or searched for. | ||
2.3 | 2.3 - 2.5 | MUST | User adds Resource List block to course that has been automatically created in Moodle. Any Talis Resource Lists appear in the block. The block matches courses to resource lists in Talis using the course code, the user should not need to do anything. |
Test Case 03: Creation of Accounts | Pass/Fail |
Test Description: Accounts are created for student and staff members who do not exist on Moodle. | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
3.1 | 3.1, 3.2, 4.1 | MUST | When a user creates a course and enrolments any user not already in Moodle has an account created. New user accounts will be created and can be searched for within Moodle. All specified fields are filled in and the authentication method is Shibboleth. |
|
|
Test Case 04: Create Enrolments | Pass/Fail |
Test Description: Users are enrolled on courses as required | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
4.1 | 4.2, 4.3 | MUST | When a user selects a course to be created in Moodle the enrolments as they stand are created in Moodle. If any users need accounts created they are created, see test 3.1. Enrolments are added into Moodle with the correct roles e.g. Student or Instructor on the relevant courses. |
|
|
4.2 | 4.4 | MUST | Newly enrolled students users have been added to the Student Help course. Newly enrolled students have been added as students onto the Student Help course unless already enrolled. |
|
|
4.3 | 4.4 | MUST | Newly enrolled staff users have been added to the Staff Help course. Newly enrolled staff users have been added as students onto the Staff Help course unless already enrolled. |
|
|
Test Case 05: Update Enrolments | Pass/Fail |
Test Description: If enrolments are updated in EUCLID the changes are reflected in Moodle | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
5.1 | 5.1 | MUST | Update enrolments Enrolments are updated, new students added as expected to the relevant courses. |
|
|
5.2 | 5.2 | MUST | Delete enrolments Where a student is removed from a course in EUCLID a student is then removed from the course within Moodle |
|
|
5.3 | 5.3 | MUST | Manually added staff remain on the course after update When a course’s enrolments are updated any manually added staff should remain enrolled on the course. |
|
|
Test Case 06: Update courses | Pass/Fail |
Test Description: When the course information changes within EUCLID this is fed through to Moodle | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
6.1 | 6.1 | SHOULD | Information is changed within EUCLID and the course management process is run If the course code, course name or category information has changed this is then updated in Moodle |
|
|
Test Case 07: Category Structure | Pass/Fail |
Test Description: Course is created in the correct place within the Category structure and categories are created within Moodle as necessary | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
7.1 | 7.1 | MUST | New course created from application. Course is put into the category hierarchy in the correct area and can be accessed through the category tree structure within Moodle. |
|
|
7.2 | 7.1 | MUST | New course created from application without relevant category already in Moodle In the case where a course is being created which doesn’t sit in the existing categories the application will create a new category to link it to. |
|
|
Test Case 08: Courses | Pass/Fail |
Test Description: Courses can be selected to have their enrolments fed into a hub course | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
8.1 | 8.1 | SHOULD | Various courses for a particular programmes are selected for a ‘hub’ course. When the user selects the hub course the enrolments from the child courses are fed into the hub course. The hub course can now be accessed by all the enrolled users. The child courses remain active on Moodle with all their enrolments functioning as normal |
|
|
Test Case 09: Integration within Moodle Admin | Pass/Fail |
Test Description: The application for managing courses should be able to be accessed from within Moodle | |
Date tested: | Tested by: |
TEST ID | BRD ref | P | Test scenario and expected outcome | Pass/Fail | Comments |
9.1 | 9.1 | COULD | User logs into Moodle, goes to Site Admin and accesses the application. User is able to run all the tests detailed above through Moodle, Moodle’s roles and permissions control access to the area. |
|
|