Before making an application publicly accessible, it is important to thoroughly test all aspects of the application process. This includes reviewing the Period and Round structure and checking to see whether data is mapping appropriately to the student record, as well as evaluating conditional logic, hard fails, application communications, and any payment integration.
Reserve time for application testing!An institution should aim to reserve 3-4 weeks during implementation to test the application before making it live to applicants.
Review Period and Round Structure
After the application build is complete, review the Period and Round structure established at the beginning of the process. If using the Slate-hosted application, ensure that the Period and Round structure makes sense for all applicants. To review Period and Round best practices, please refer to this article: https://knowledge.technolutions.com/hc/en-us/articles/360032864991-Period-and-Round-Structure
- Is the Period name descriptive?
- If there are multiple Periods, is the decision process intuitive for applicants?
- Do the Rounds accurately reflect the different application types?
- Is it clear which Round an applicant should select?
The answer to each of the above questions should be "yes."
If importing application data, review the structure and make sure it is possible to map applications to the appropriate Period and Round. Make sure application Rounds reserved solely for imported applications are set to "Inactive" so they are not available in the public-facing application selection palette.
Create a Test Application Record
- Select Lookup on the top navigation bar.
- Select New Person.
Enter an email address, first name, last name, and birthdate, and click Create.
Be sure to enter a valid email address to which you have access.
- Go to the Profile tab on the new person record, and select Account in the right-side menu.
- Select Reset on the password row to generate a temporary login PIN for the new record.
- Open an incognito window in Chrome (Use an incognito window to experience the account login and application creation process as an applicant. Continuing in the same browser, you will remain logged in as an administrator).
- In the incognito window, navigate to the default application landing page (for example, slateuniversity.edu/apply).
- Select Log in.
- Enter the email and PIN, and proceed through the login process to set a new password.
- Select Start New Application to create a new application for this test record.
Design a Comprehensive Test Plan
When the application build is complete, design a process through which all aspects of the application will be tested. An institution should involve multiple members of the implementation team in application testing to make sure there is consensus on application flow and pages.
The goal should be to test all possible ways an applicant may complete the application. A testing plan should account for every possible application type and program combination to ensure that the application functions properly and that all data is mapped and stored properly in Slate. To fully test the application exactly how the applicant experiences it, be sure you are testing in an incognito browser. You can follow the below steps to ensure a true testing experience:
- Right-click on the "Impersonate application" link on the right side of an applicant's application tab and choose "open in incognito mode".
- In the new window, log in to Slate.
- Once logged in, right-click on the tab you have open and select "Duplicate".
- In the new tab, click the Logout option in the top right corner and press enter. This should log you out as an administrator.
- Return to your other open tab and click refresh. You should now be authentically impersonating the applicant and seeing what they would see.
Take Inventory of Application Pages and Questions
Review each page in the application, and the questions asked on each page. Make sure all settings are configured as desired in the Application Editor and check that all fields on custom application pages are mapped.
Review Hard and Soft Fails
Before filling out a test application, review the hard and soft fails configured in the application logic. Make sure all required data points have a corresponding hard fail, and that all recommended data points have a corresponding soft fail.
Hard fails can also be used to enforce application deadlines and other submission criteria. For additional information on submission requirements, please visit Submission Requirements.
Begin Testing the Application
Execute the testing plan to ensure the application is functioning as expected.
Fill Out the Application
Use test records to complete the application. The best practice recommendation is to complete the application using an incognito window in Chrome to observe the true applicant experience.
When filling out the application, pay careful attention to:
|Area to Test||Action|
|Field Values||Make sure that all field values are stored properly and are mapped to the correct destinations.|
|Material Uploads||Make sure that any files uploaded in the application are saved and mapped to the materials section on the application record.|
|Test any standard widgets (school history, test scores, employment history) and custom widgets added to the application.|
|Test both the applicant-facing and recommender-facing experiences.|
|Make sure the digital portfolio upload functions properly and saves to the correct material type.|
|Ensure that video essays are recorded and saved properly.|
Test conditional logic throughout the application to ensure that it is functioning as required.
|Area to Test||Action|
|Group/Page Keys||Test group/page key logic to confirm that application pages are displaying to the correct applicants.|
|Test form logic on custom application pages to make sure that questions are displaying appropriately. Also, test any configured prompt conditions to confirm that the correct options are displaying.|
Test Submission Requirements
Make sure that the configured hard and soft fails are triggered on the review page as desired. Hard fails should prevent the submission of an application by the applicant. Soft fails should display a warning, but ultimately not prevent the applicant from submitting the application.
Make sure that application payment activities are being applied to application records appropriately. If a payment is required to submit an application, confirm that application submission does not bypass this step (unless you are logged in as an administrator).
Once the payment activity is applied to the application record, test the payment process. If an integration has been established with an external payment provider, test the payment gateway.
Payment integration with an external payment provider can take additional time to complete. Please allow at least 30 days for the payment integration to be provisioned, configured, and tested.
For more information on payments in Slate, refer to the article on Payments.
Test System Emails
Make sure that all configured system emails associated with the application submission process have sent and that the email content is accurate.
Test Status Page
Preview the status page to confirm that checklist items display properly for all types of applicants. Check that any custom status pages display and function appropriately for all types of applicants including static content, custom checklist sections, social media feeds, and redirects.