Testing an Upgrade

Last updated
Save as PDF

Before you begin

Before you begin, determine what Type of sandbox you will use and if you need to refresh before testing the upgrade. Review the articles below for steps on refreshing and setting up various products in your sandbox.

Preparing for your Upgrade

When you are ready to upgrade, assess what needs to be tested. Review the Release Notes and Resolved Defects lists to determine what packages are updated in the release:

Create a list of any automated updates, workflow, or process builder processes you have set up.
Set up Test Data based on WHAT needs to be tested (for example, test Student records, test Event Records, etc.).
- If you are using a Partial or Full sandbox, you can choose to copy some or all of your data from production.
- If applicable, set up Payment Connectors in your sandbox. Your Payment Vendor can provide dummy payment information to test payments.
Test anything mentioned in the release notes or resolved defects for products you use:
- This might include testing email functionality, SMS functionality, app review functionality, event functionality, etc.
Test your Day-to-Day processes.
- Be sure that your users test their day-to-day activities. Have users with different profiles edit records, review Applications, create/edit Events, etc.
Test your Critical processes.
- Identify which processes are critical to your institution. This might include things like Online Application, Payment Processing, Email Campaigns, etc.

Sample Test Scenarios

The following are sample test scenarios for 'out of the box' functionality. Your Org may have automated updates, workflow, or process builder processes you have set up which should be evaluated and added to ensure your Upgrade testing is thorough and complete.

General CRM

Automated updates/fields updating based on triggers
Formula fields, such as Prospect Scoring formulas
Workflows or Process Builder processes.
- For example Student Stage, other institution-specific automation
Verify that ALL of your Source to Master configurations are working as expected:
- Enrollment History
- Inquiry
- Test
- Application
- If applicable, you can see details on how to configure Source to Master to update the Account to the most recently modified Enrollment History record in the User Community article: How to use Source to Master to update a Contact's Account based on Enrollment History.

Portal

Test Condition Sets
Test adding a Video Widget
Test adding a Rec Widget
Test Merge fields
Navigate through the various Portal pages, test links
Log in to your Portal(s) as a Student.
If you have multiple Portals, repeat the above tests for EACH ONE.

Email

See the User Community article Testing emails in a sandbox instance.

Test creating and previewing Queries to ensure a proper Recipient list.
Test creating and previewing Condition Sets.

Events

Forms/Events - Create a separate form used to connect to the sandbox to thoroughly test form submission and event registration.
- The form is set up in production but the Connector looks to sandbox and the Form Redirect needs to go to the sandbox Event Site.
Test the External Events Calendar (visible to prospective contacts); filter Nearby Events, My Events, by Type, etc.
Register for different events as a student (with and without a Guest):
- Featured Event
- Recurring Event
- Event with sub-events
Confirm correct Confirmation/other automated Emails sent correctly. Note: SalesForce email needs to be enabled for this to work.
Test Event Reminder Emails to confirm correct number of days. Note: SalesForce email needs to be enabled for this to work.
Cancel an Event registration.
Check in an Event Registrant.

Appointment Scheduler

Login to your Appointment site as a user
Create availability in the Appointment Calendar as a user
Sign up for an Appointment with a staff member

Online Application

Thoroughly test creating a new user for the online app by completing the following (note: we recommend completing these steps in a Private window):
- Signing up for an account
- Clicking the link in the email
- Setting up the password and logging in.
Complete an Application as a student for each population. For Examples: Domestic freshman, International Freshman, Domestic Grad, International Grad, Domestic Transfer, etc.
Logged in as a student, attempt to complete various tasks in the Application, both expected and unexpected:
- Examples of 'expected' tasks might be as follows:
  - Log in, enter Contact information, enter 1 or 2 Enrollment History records, 2 to 3 Recommendations, etc.
  - Make a successful Payment and Submit the Application.
- Examples of 'unexpected' tasks might be as follows:
  - Enter Enrollment History for 14 different schools, put in 30 different test scores, and create multiple apps for various programs in the same term; if the configuration allows this.
  - Submit a failed payment, request a waiver, etc.
- With 'unexpected tasks,' you are essentially trying to capture the 5% of your population that inevitably enters unexpected data and causes the Application to behave in strange ways.

Retention

View student information/profile.
Add Referrals, Holds, and Kudos.
Create an Action Plan for a student (if configured).

Group Assignment

Create a new Assignment Group; add Members, Criteria.
Verify you can Add members to the new Assignment Group.
Create a new Student record and verify the group is assigned correctly.
Workflows or Process Builder processes.
- For example Group Assignment/Contact Owner

Application Review

Using a new Application record, create a new Application Review.
- Be sure to test each Review Type/Assignment and verify reviews are created/assigned/routed as expected.
Log in as a Review User and verify you can read and review the Application.
- Score the Application and Submit it.
Validate any related Workflows or Process Builder processes.