Admission Portal 3 Testing Guide

Overview

Testing your Admission Portal 3 (AP3) configuration is the final and arguably most critical piece of your AP3 launch. This article outlines how to approach testing in your own admissions office, recommends tools and best practices, and offers example scenarios.

Testing Scenarios: The Big Picture and Examples

We recommend developing a series of testing scenarios. These represent the candidate scenarios you need your admission portal to support given variations in your applying community and your internal processes. There are three different classes of testing scenarios: demographic, process-specific, and option-based.

• Demographic scenarios represent the different kinds of families you expect to progress through your admission process using your admission portal. These scenarios emerge from different numbers of included parents, different numbers of included children, different relationships between children and parent, and different candidate and parent genders.
• Process-specific scenarios represent sub-sections of your candidate pool that require different admissions steps (modeled by different checklist items) or different internal review processes (usually identified by profile-codes or system groups).
• Option-based scenarios represent the different potential paths a portal user might take in each stage of the admission process: inquiry options, optional checklist items, optional demographic updates, and candidate change requests.

Example Demographic Scenarios

• Parent Numbers / Relationship with Child Examples (R=resident; NR=non-resident)
  • single parent
  • two parents: mom and dad; dad and dad; mom and mom; mom (R) and dad (NR); dad (R) and mom (NR); mom (R) and mom (NR); dad (R) and dad (NR)
  • three parents: mom (R), step-dad (R), and dad (NR), etc.
• Child Numbers: one candidate, two candidates, three candidates, etc.
• Child Genders: male, female, non-binary (or non-binary option set)

Examples of Option-Based Scenarios

• If you have multiple inquiries, each inquiry represents a different option-based scenario.
• If you have optional checklist items (open house, shadow visits, etc), each checklist item represents.
• Assuming you are enabling parent/relative demographic updates (on by default), each available update form represents an optional scenario.
• New candidate form submissions (even though, technically speaking, this is the required process by which anyone with a Veracross account will register a new candidate).
• "Request a change" submissions.

Examples of Process-Specific Scenarios

• A set of checklist items that should only be created for candidates applying to a grade level (or range of grade levels).
• A set of checklist items that should be created for international students only.
• A set of checklist items that should be created for candidates requesting financial aid.
• A profile code that needs to be added to a candidate based on a profile code web form element.
• An inquiry review process that is specific to a given inquiry or inquiry preset.

Testing Scenarios: Write Your Own

Using the above examples of demographic, option-based, and process-specific scenarios, develop your own testing scenarios relevant to your own prospective constituents. 

1. Write out a profile for 3-5 families representing different demographic scenarios you want to test.
2. List out the option-based scenarios you want to test.
3. List out the process-specific scenarios you want to test.

Create Testing Email Addresses

We recommend setting up one new test account with Gmail, and then using Gmail's "+" method (as outlined in #1 on this article) for differentiating this account for testing purposes.

Document Scenarios and Results

Writing out the testing scenarios is only half of the documentation need. It is also important to document the testing results and feedback so that you can:

• ensure that all scenarios are run
• produce feedback to improve your processes

We recommend using a shared Google Doc or Office365 Word document to list and report testing results and feedback as your testing team works through scenario testing.

Run the Tests

1. Test each inquiry using each test family you have listed, as needed, register additional family members using the Parents & Addresses forms and "Add Candidate" form in the portal.
2. Test each option scenario you have listed with one of your test families.
3. Test each process scenario you have listed with one of your test families (as necessary, you can add new--process-specific--candidates using the Add Candidates form.

Naming Your Test People

1. Include the word "Test" in the last name.
2. Recommended: Include an abbreviation of the demographic scenario of which this test person is a part. See examples:

Testing Inquiry and Demographic Forms

Portal Experience Testing Notes

1. To begin a new inquiry, click "Public Form URL" on the Inquiry Form Detail Screen. See screenshot below.
2. Fill out the inquiry as if you were a parent in the profile family.
3. After submitting the form, record in writing if the result was not what you expected.
4. For inquiries configured to registering just one parent, proceed to the confirming the account and logging on to the portal to add additional parents (as necessary).
5. Siblings can be added as candidates on the portal (via Add Candidate) or as non-candidate siblings (using the Relatives and Friends form).

An Inquiry Form detail screen. 

Submission Review Testing Notes

1. For inquiries set to a submission strategy of "Requires Review", all staged submissions come into the "Pending Inquiries" report on the Candidate Changes homepage. See screenshot below.
2. For inquiries with a submission strategy of "Immediate", as well as for processed staged inquiry submissions, inquiry submissions are listed in descending order of submission date on "Inquiry Submissions" report on the Candidate Changes homepage. See screenshot below.
3. As needed, your team can build inquiry-specific submission review queries using the above two reports as a starting place, saving them to your shared Candidate Review workspace.

 The "Pending Inquiries" and "Inquiry Submissions" queries

Testing Parents & Addresses Forms

Portal Experience Testing Notes

1. Log onto the portal using one of your test parent user accounts or access the portal via impersonation of a parent test account.
2. Continue to the My Family / Candidates page and click Parents & Addresses. See screenshot (gif) below.
3. Add additional parents and addresses based on the family profile you are testing for
4. If you configured them as active for your Implementation, test adding and updating the following:
   • Parent Employers
   • Parent Education
   • Parent Citizenships

Submission Review Testing Notes

1. For Parent & Addresses forms set with a submission strategy that requires review, all staged submissions come into the "Pending Household Changes" report on the Candidates Changes homepage. See screenshot below.
2. For Parents & Addresses forms with a submission strategy of "Immediate", as well as for processed staged P & A form submissions, the submissions are listed in descending order of submission date on the Household Update Submissions report on the Candidate Changes homepage. See screenshot below.
3. As needed, your team can build specialized review queries based on specific forms, starting with one of the two above reports, saving them to your shared Candidate Review workspace.

Find forms requiring review in the "Pending Household Changes" report and immediate ones in the "Household Update Submissions" query.

Testing Checklists

Use process-specific testing to confirm that the expected checklist items are created for different candidates, especially if specialized checklist items need to apply to given candidate profiles.

1. Submit and process (if "Requires Review") an Inquiry or New Candidate form as a test parent, making sure to set your candidate data within the scenario you wish to test
   • For example, if there is a checklist item that should only apply to candidates applying to the 7th grade, ensure you have set "Grade Applying For" to 7th Grade
2. In Axiom, on the Candidate Changes homepage, find your submission on the Recent Activity report, and use this submission to navigate to the newly-created candidate.
3. On the candidate's checklist tab, confirm the checklist set matches what you scenario expectations (given your Registration Season Checklist configurations). See screenshot below.

The "Checklist" tab of a candidate detail screen. 

Testing Checklist Forms

Setup

Open this report to review current season registration season checklist items that are wired up to checklist forms. These represent the forms you should test.

Portal Experience Testing Notes

1. Log onto the portal using one of your test parent user accounts (OR access the portal via impersonation of a parent test account).
2. Continue to the My Family / Candidates page. See animated screenshot below.
3. Click "View Checklist" on the candidate from which you want to test a set of checklist forms.
4. For each item representing a checklist form.
   • Proceed through the "Add" version of the form and submit.
   • As configured to be possible, proceed through the update version of the form and submit.

Submission Review Testing Notes

1. For checklist forms set with a submission strategy that requires review, all staged submissions come into the "Pending Checklist Submission" report on the Candidates Changes homepage. See screenshot below.
2. For checklist forms with a submission strategy of "Immediate", as well as for processed staged checklist form submissions, the submissions are listed in descending order of submission date on the Checklist Submissions report on the Candidate Changes homepage. See screenshot below. 
3. As needed, your team can build specialized review queries based on specific forms, starting with one of the two above reports, saving them to your shared Candidate Review workspace. 

The "Pending Checklist Submission" and "Checklist Submissions" reports on the Candidates Changes homepage

Admission Visit Checklist Widget Testing

Setup

• Open this report to review current season registration season checklist Items with one of the "visit" checklist widget types.
• There are three different types of "Admission Visit" widgets you may have configured for your Admission Portal: Admission Visit Slots, Admission Visit Date, or Admission Visit Drop Down. The visit event integration for each of these widget types is configured on the Registration Season Checklist Item Detail Screen.

An example of an "Admission Visit" checklist item. The widget settings vary depending on the widget type. 

Portal Experience Testing Notes

1. Log onto the portal using one of your test parent user accounts (OR access the portal via impersonation of a parent test account).
2. Continue to the My Family / Candidates page. See screenshot below. 
3. Click "View Checklist" on the Candidate from which you want to test the "visit" checklist item(s).
4. If the admission visit item(s) is organized into a non-active checklist category, click the category, then click "Sign Up" on the item widget. This activate the sign-up interface corresponding to the widget type. See screenshots below.
5. Complete the Sign Up form and click "Submit"
6. Confirm the status change of the Admission Event widget matches expectations. See screenshot below.
7. For at least one of your tests, click the "Reschedule..." button to test a Reschedule scenario. See screenshot below.

The "Sign Up" buttons for each of the three widget types

The "Sign Up" interface for each of the three widget types.

Note the "Scheduled" statuses and the "Reschedule" button.

Admission Visit Admin Testing Notes

• For schools converting from Admission Portal 2.0: There is no change in the way admission event signups are entered into Veracross. For your admin testing, you can simply confirm that your various visit reports are picking up the new sign-ups as you test making them.
• For schools implementing Admission Portal 3.0 as a new install: Work with your implementation manager to talk through how to set up the visit reports you need to run your various school visits types as parents sign up through the portal.

Testing Recommendation Forms

Setup

Open this report to review current season registration season checklist items with a "Recommendation" checklist widget type.

Portal Experience Testing Notes

1. Log onto the portal using one of your test parent user accounts (OR access the portal via impersonation of a parent test account). See animated screenshot below.
2. Continue to the My Family / Candidates page
3. Click "View Checklist" on the Candidate from which you want to test a Recommendation checklist item.
4. If the Recommendation item is organized into a non-active Checklist Category, click the category, then click "Send Recommendation Request" button on the Recommendation Item widget.
5. Enter "Test Recommender" as the recommender's name, and enter an email address you can access for testing.
6. Confirm the status change of the Recommendation Item widget matches expectations.
7. Find the email set to "Test Recommender" in the email account you are using to test recommendations.
8. Complete and submit the Recommendation Form.
9. As your test Parent user, refresh the Candidate Checklist page showing the Recommendation Widget.
10. Confirm the status change of the Recommendation item widget matches expectations.

The process of testing an admission recommendation form. 

Recommendation Admin Testing Notes

• For schools converting from Admission Portal 2.0: There is no change in the way Submitted Recommendations are entered into Veracross. For your admin testing, you can simply confirm that your various recommendation reports and other workflows are picking up the new recommendations you have submitted.
• For schools implementing Admission Portal 3.0 as a new install: Work with your implementation manager to talk through how to set up the recommendation admin workflows you need to run your various recommendations that will be coming in from teachers as promoted by portal users.

Testing Required Checklist Item Completion

• You can simulate a candidate completing all required checklist items by opening their candidate detail in Axiom, navigating to the Checklist tab, and marking all their required checklist items "complete."
• Log onto the portal using one of the test parent of this candidate user accounts (OR access the portal via impersonation of this parent's test account).
• Continue to the My Family / Candidates page.
• Identify the Candidate for whom you just completed all required checklists.
• Confirm that the requirement completion message matches expectations.
• Click "View Checklist."
• Confirm that the requirement completion message matches expectations.

Check the number of completed checklist items that are required.

Remove Test Data

When you are all done testing, it is important to remove all testing data so your numbers are "clean" when you launch your Admission Portal.

Removing Test Candidates

• Open the candidate detail for the test candidate you wish to delete.
• Delete all relationships on the Related People tab. See screenshot below.
• Click the "Recommendations tab", remove any recommendations if there are any.
• Click the "Admissions History" tab. If an Application ID exists, click it. Then delete the Application Record via the "+" button the the Application Detail. See screenshot below.
• Navigate back to the Candidate detail screen.
• Remove the Candidate by clicking the "+" button on the Detail and selecting "Delete." See screenshot below. 

Delete all relationships of the test candidate. 

Click the "Application" ID on the Admission History tab of a candidate detail screen to access the application you are going to delete.

To delete an application or a candidate, select "Delete" from the Organize (+) menu. 

Removing Test Parents

• Open the detail screen for the parent you wish to delete.
• Delete all relationships on the Related People tab.
• If this test parent has a user account, remote the VC User account via the Action menu. See screenshot below.
• Remove the parent by clicking the "+" button on the detail and selecting "Delete".

To remove a test user account, click "Remove VC User Account" from the Action menu of a person's detail screen. 

Removing Households

• After deleting all test people in a household, navigate to the household detail for the test household you wish to delete.
• Remove the household by clicking the "+" button on the detail and selecting "Delete".

Veracross Removing Test Data

• Identify all the person records you wish to delete by tagging them with a common profile code.
• Create and save a query including all "to be deleted" people who are tagged with this profile code.
• Work with your account manager to schedule a time for Veracross engineers to remove these test people and associated test households.