Schedules

Manual Testing Protocol

When testing schedule changes, there are three areas we need to confirm:

• The schedule exists in the sandbox after the merge request is created
• A comparable JSON object from the API matches what is in the YAML file
• The schedule is applied to an appropriate ticket

The schedule exists in the sandbox

This is a test the Sandbox sync from the merge request created the schedule properly. To do this test, login to the Sandbox (as an admin), and navigate to Objects and rules > Business rules > Schedules in the admin panel. If the schedule you are creating/updating is listed there, the test passes.

API object matches YAML object

This requires reviewing the API object from the Zendesk Sandbox and the YAML object from the file you are editing. Ensure the values of the following keys match:

• name
• time_zone
• intervals

The test passes if the values between the two objects match exactly.

The schedule is applied to an appropriate ticket

This requires filing a ticket using criteria in which the schedule would normally be applied (this usually involves knowledge into the triggers that would do so). File a ticket using the test_user defined in the file using the correct form/fields. Then check the events after everything is done updating the ticket. The test passes if the final schedule change in the events is to the schedule you are creating/editing.

Test Suite Script

Presetup

Before running the script, ensure the following has been done:

• GITLAB_TOKEN is defined in your environment
• SB_ZD_SECRET is defined in your environment (for Zendesk Global testing)
• SB_ZD_CLIENT_NAME is defined in your environment (for Zendesk Global testing)
• SB_ADMIN_EMAIL is defined in your environment (for Zendesk Global testing)
• SB_ADMIN_PASSWORD is defined in your environment (for Zendesk Global testing)
• US_SB_ZD_CLIENT_NAME is defined in your environment (for Zendesk US Government testing)
• US_SB_ZD_SECRET is defined in your environment (for Zendesk US Government testing)
• US_SB_ADMIN_EMAIL is defined in your environment (for Zendesk US Government testing)
• US_SB_ADMIN_PASSWORD is defined in your environment (for Zendesk US Government testing)

As this will involve a login as an admin/agent, you should also have the admin page for that user ready to generate recovery codes.

How it works

The script runs in “stages”:

• Pre setup
  • This stage defines various core functions for the script to use (various Faraday connections primarily)
• Pre tests
  • This stage checks to ensure Presetup has been done correctly. It will check for
    • the environment variables it needs to run
    • the current branch you are in is not master or main
• Definitions
  • This stage defines various variables that are needed for the script to use
• GitLab Info
  • This stage locates the merge request for your git branch, the corresponding parent issue, and the schedule changes that have been made within the merge request.
• Schedule tests
  • This stage defines the tests to do and performs them
  • For each schedule change detected previously, a child task item is created (linked to the parent item)
  • As the tests are performed, it will add comments to the corresponding child task item with the details of the test and the results
    • If browser testing was done, screenshots should be provided on the comments made
• Postrun instructions
  • This stage adds a summary comment on the parent issue (linking to all child task items)
    • It will also point to the location of all screenshots created in case the upload failed for any tests

For a more detailed explanation, please see the corresponding recording (internal link).