Test the form applicants will actually use before opening a new cycle or publishing a significant revision. This checklist helps an admissions team confirm that applicants see the right questions, can correct mistakes and understand whether their application has been submitted. It works with any application platform.
Set up the test
Record the application name, cycle, configuration or version, test date and testers. Agree on the expected behavior before testing; otherwise two people can mark the same result differently.
Assign a release owner and identify which scenarios are required for this release. Replace the First-year and Transfer examples below with the applicant paths your institution actually offers. Keep at least one test that changes an answer controlling a conditional section.
Use fictional applicants in an approved test environment. Identify any external messages, fees or record transfers that need a separate test arrangement. Include a desktop browser and a narrow phone screen, and complete a keyboard-only pass.
Prepare at least these paths:
- A First-year applicant who should see the First-year section.
- A Transfer applicant who should see only the sections relevant to that path.
- An applicant who switches First-year to Transfer to First-year after entering an answer in a conditional section.
- An incomplete application that needs at least one required answer corrected.
Record each check as Pass, Fail, Not tested or Not applicable. Give a reason for Not applicable. A result counts as Pass only when you have observed the expected behavior. For each scenario, record the expected result, actual result, fictional record identifier, configuration or version and evidence location. Use screenshots or notes without real applicant information. Do not let one passing path stand in for another required path.
Check the form and its questions
1 Confirm the layout
Open every page or section on desktop and phone. Read the labels, instructions and choices in order.
Pass when: the intended questions appear in the intended order; labels and instructions are readable; controls do not overlap or run off screen; required status is clear.
Result: __________ Evidence or issue: ______________________________
2 Follow the form with a keyboard
Move through fields, choices, links and buttons without a mouse. Check focus visibility and message readability, including at increased browser zoom.
Pass when: every required interaction is reachable, focus follows a usable order and errors can be understood without relying on color alone. Treat this as a practical check, not a complete accessibility assessment.
Result: __________ Evidence or issue: ______________________________
3 Check each conditional path
Select First-year, then test Transfer in a separate fictional application. Compare the visible questions with the agreed rules.
Pass when: each path shows the intended questions and instructions. Questions that do not apply do not prevent progress.
Result: __________ Evidence or issue: ______________________________
4 Switch a path after entering an answer
Enter a recognizable fictional answer in a First-year-only section. Switch to Transfer, then back to First-year.
Pass when: section visibility changes correctly and the treatment of the earlier answer matches the agreed policy. Check whether the answer is retained, cleared or excluded from later review. Confirm that hidden required questions do not unexpectedly block the active path. If the intended answer-handling policy is unknown, resolve it before marking Pass.
Result: __________ Evidence or issue: ______________________________
5 Find and correct a required answer
Leave one applicable required question empty and attempt the next permitted action. Follow the error, supply an answer and try again.
Pass when: the message identifies the missing answer, the applicant can reach and correct it, the error clears appropriately and other answers remain intact.
Result: __________ Evidence or issue: ______________________________
6 Test field limits and formats
Try an invalid value, a valid boundary value and an ordinary valid value for fields with dates, lengths, numbers or other format rules.
Where the form allows them, include names with spaces, hyphens or apostrophes and an international address or phone number. Use the institution’s agreed rules to decide what is valid, not assumptions about one country’s format.
Pass when: valid values are accepted, invalid values receive a useful explanation and the instructions match the rule being enforced.
Result: __________ Evidence or issue: ______________________________
Check progress and completion
7 Move backward and forward
Enter answers, move to the next section and return. Repeat after correcting a validation error.
Pass when: answers that should persist remain intact, progress reflects the actual state and navigation does not silently discard work.
Result: __________ Evidence or issue: ______________________________
8 Check saving and returning when supported
Save using the platform’s documented process. Close and return to the same fictional application.
In the approved test arrangement, also interrupt the connection before a save is confirmed. Reconnect and verify what was actually stored. An unconfirmed save may still have reached the server; do not assume either success or failure. Note whether the applicant can determine which answers were saved.
Pass when: after a normal save and return, the answers and application status match the last confirmed save. After an interruption, the returned record and save status agree with the verified stored result, and the interface does not claim success before it can verify it. If saving and returning are outside the form’s scope, record Not applicable and ensure applicants are told what to expect.
Result: __________ Evidence or issue: ______________________________
9 Review the completed answers
Use the platform’s review step, or another agreed view of the fictional record, before the final action.
Pass when: answers are accurate, the selected applicant path is clear and hidden or inactive answers are handled according to policy. Correcting an answer returns the applicant to a usable review state.
Result: __________ Evidence or issue: ______________________________
10 Verify submission separately from draft progress
In the approved test arrangement, complete the final submission action and check the resulting application state and receipt.
Where the test arrangement permits, also check a repeated final click or a retry after an interrupted response. Confirm the agreed handling of duplicate attempts in the receiving record and any separately tested fee or notification flow. Do not repeat a live payment or message merely to exercise this case.
Pass when: the system confirms a successful submission and the receiving application record shows the expected submitted state. For any required retry case, duplicate attempts are handled according to the agreed policy, without unintended duplicate records or side effects. A cleared error, completed page, saved Draft or disabled button is not sufficient evidence. If the test stops at Draft, record final submission as Not tested. Record an untested retry case separately rather than implying it passed.
Result: __________ Evidence or issue: ______________________________
11 Confirm the receiving staff view
Find the same fictional submission in the staff view or destination that is part of this release. Compare its identity, answers and expected status with the applicant’s result.
Pass when: the intended record is available to the appropriate staff and matches the submitted example. If another system, upload, fee or notification is required, attach its separate test result. Do not assume those steps succeeded because the form submitted.
Result: __________ Evidence or issue: ______________________________
12 Check the exact release and existing applications
Identify the version or configuration to be published. Test a new application and, where relevant, an application started before the change.
Pass when: new applicants receive the intended release and existing applications behave according to the agreed change policy. Check form structure and independently managed rules separately where the platform distinguishes them.
Result: __________ Evidence or issue: ______________________________
Record the release decision
Form and cycle: __________________________________________________
Version or configuration: __________________________________________
Test environment and date: _________________________________________
Testers and devices or browsers: ____________________________________
Required scenarios and evidence location: ___________________________
Unresolved issues and owners: ______________________________________
Accepted lower-impact issues and resolution dates: ___________________
Retest completed by and date: ______________________________________
Decision: Release / Hold
Approved by and date: ______________________________________________
Release only when the required checks pass. Record why any check does not apply. A required check marked Fail or Not tested means Hold. If a lower-impact issue is accepted, record its scope, owner and resolution date; do not relabel the failed test as Pass.