Skip to content

CRM Testing and Validation

Jump to bottom Edit New page
Kyle edited this page Aug 5, 2014 · 25 revisions

Description

This page is used to describe the areas of CRM which are tested and how they are tested before a release. This approach is to ensure that a comprehensive testing process is completed before a release.

If a test fails, a new tracker issue should be released and added to the most recent milestone.

Block Links and Icons

  • Check all links are working
  • Check all icons are showing
  • Add Block to a My Moodle and check all are still working correctly.

Making a Request

Make a request selected from block

- /course_request.php?mode=1 When a new request is created, all fields should be blank.

  • Shortname (tf)
  • Fullname(tf)
  • Mode (select box), switched on from config

Buttons:

  • Continue

  • Cancel

  • Verify spelling on page.

  • Check header links work correctly

During this process, if a course with a similar code or name is found the following can happen:

  • New module if no similar are found.
  • Show existing to allow request of the module if the user desires.

- course_new.php

Dynamic Fields based upon the fields that have been added to the from Selecting of a different from should impact the current shown form.

Buttons:

  • Continue
  • Cancel Request

Page:

  • Verify spelling.
  • Check header links work correctly

- review_request.php?id=1

A review of the request - Fields shown should be representative of those that are added to the current summary.

Buttons:

  • Submit Request - Submit the request to the system, sending the user to the page outlining their requests. *(module_manager.php)
  • Alter Request - Bring the user back to the editing mode, populating the fields with the selected values. (page should be in editing mode, containing previous values)
  • Cancel Request

Page:

  • Verify spelling.
  • Check header links work correctly

Manage your requests

  • Ensure only the current users requests can be seen, no other requests should be visible to the user.
  • Check nav bar links to ensure the text and links are correct
  • Requests should be ordered by oldest to the top, newest to the bottom.
  • Comment on the module, only the latest comment should be seen when viewing the record.

Buttons:

  • Request a new course setup - This button will initiate the course request process, creating a new record.
  • View - Allow the contents of a single record to be viewed.
  • Edit - Edit an existing record.
  • Cancel - Deletes a request the user has made from the queue.
  • Comment - Allow the user to leave a comment on the record.

My Archived Requests

List of the requests which have been completed by the system, or marked as denied by the admin.

  • Check links on nav bars work, and that footers are added correctly.

Buttons:

  • Request a new module button - Allow the user to make a new request (uses existing process).

Request Queue

cmanager_admin.php

  • Check to ensure the header and footers are on the page.
  • Check that content which is printed in the list, is exactly the same as the content which has been added by the user to the record.

Buttons:

  • Quick Approve - Javascript option that allows a course to be approved (uses bulk approve back end), send out approve mail. Mark request as APPROVED.
  • Deny a course - Mark a record as denied and send out deny mail. (see below)
  • Back button, allowing user to return back to admin list of modules
  • Add / View comments - See the list of comments for the module and leave a comment as a module
  • Delete - Delete the record from the system. Will no longer be visible from user or admin side.

Category option - Allow the admin to change the category of a record on the fly.

Options to the left hand side of the admin screen ---->

  • Bulk Select - Select All of the records currently added to the system. ** Bulk deny Select All records option

/admin/comment.php?type=adminq&id=19

  • View list of comments added to the record from the admin perspective.
  • Add a comment and mail the comment to the user

deny_course.php?id=17

  • Show list of pre defined deny reasons, allow the user to add them to the text which is sent to the user.
  • Mark record as DENIED.
  • Send out mail to user.

Search Options Textfield to answer text,

  • Shortname
  • Fullname
  • Author

PREVENT Blank Search

All Archived Requests

/cmanager_admin_arch.php

  • View list of records that have been archived
  • Check page counter at top of page is correct

CManager Config

cmanager_adminsettings.php

  • Check course naming convention is properly utilized
  • Check short name formats are applied
  • Check enrolment keys option exists
  • Check clearing of history works
  • Test self cat process when enabled, should allow the user the option to categorize their course.
  • Coms email address is the one set
  • Settings are saved when changed and save is pressed at the bottom of the page

Additional Checks

Roles

  • Ensure that the roles are correctly defined.
  • Ensure that guests do not have permission to use CRM.

Version Numbers Check the release numbers are correct

Installation process of block

  • Ensure the script executes only once adding the needed variables.

Cross Browser Testing

  • Language Strings

Cross Theme Testing

  • Native theme
  • Alternative theme

Hardcoded mdl_ references

Documentation

  • Update Official Documentation Moving away from PDF based files, all documentation is on the moodle.org wiki. Ensure the links are updated to the latest version.

  • File headers contain references to the correct versions.

  • README file contains updated information.

  • List of addressed changes in the changes.txt file are added, or links to milestone on github.

Add a custom footer
Add a custom sidebar
Clone this wiki locally