A preview can show a tidy form while missing the problem that will stop the first customer: an email requested twice, a birth-date picker that takes too long to navigate, or a displayed date that never reaches the saved record. Testing needs to follow the whole interaction, including what staff see afterward.
Set aside a clearly labeled internal test template and use fictitious details. The goal is not to prove that every possible input works. It is to check the paths your customers depend on, find failures before they reach the desk, and make the results easy for someone else to repeat.
Download the waiver testing checklist (CSV). It includes test cases, expected results, and empty columns for actual results and follow-up. Keep a copy with the template version you tested.
Start outside your staff session
Open the public signing link in a private browser window. You should see the intended venue, activity, and form without access to the staff dashboard. If the link comes from a QR sign or booking message, open that actual link rather than a convenient shortcut from the editor.
Check that the first screen explains who should complete the form and what happens next. If a guardian is signing, the instructions should make that role clear before the person starts entering details. A form title that makes sense to staff may not make sense to a first-time visitor.
Record the date, template version, device, and browser you used. A note saying “mobile works” is hard to investigate later. “Phone, browser, adult route, version, completed at this time” gives the next reviewer something concrete to reproduce.
Check identity fields across steps
Enter an email address on the first step. Continue and see whether it carries forward where the same signer's email is needed. If a later field is intentionally for a different person, its label should explain that difference.
Try a name with a space, apostrophe, or hyphen, using fictitious data. Check that the same spelling appears in the confirmation and saved record. Do not require a name to fit a narrow format just because your own name does.
For dates of birth, test an older birth year as well as a recent one. Count the effort involved. If reaching a year several decades back means tapping a previous-month arrow hundreds of times, the control is not ready for a mixed-age audience. Confirm that month, day, and year remain clear after selection and that the stored date matches.
Test any prefilled signing date without touching it. A value that looks filled in must still be validated and saved correctly. Then change it, if the form permits changes, and check that the submitted result follows the applicable rules. Display and submission are separate things to verify.
Make the form explain its errors
Submit once with a required field missing. The form should identify the field and explain how to fix it without losing the answers already entered. “Something went wrong” leaves a customer guessing.
Try a malformed email address, an incomplete date, and any choices specific to your form. Check that optional questions really are optional. If declining optional consent prevents participation, inspect both the requirement setting and the associated wording.
W3C's form guidance recommends clear labels and useful validation feedback. A placeholder that disappears after typing is not a substitute for a persistent label. Error text should identify the problem and help the person correct it. See the W3C labeling guidance and form validation tutorial.
Do not test errors only by looking for red styling. Read the message, follow the focus position, and check whether the person can reach the affected field with a keyboard.
Cover the paths your venue actually uses
A single successful adult submission does not test a family form. Build a small test matrix around the features you enabled rather than dozens of unrelated cases.
| Test case | What a passing result should establish |
|---|---|
| Adult completes the standard form | Identity, answers, acknowledgement, and signature reach the correct record. |
| Guardian lists two minors | Both children remain associated with the intended guardian and submission. |
| Required answer is omitted | A useful error appears and existing answers remain available to correct. |
| Optional consent is declined | The intended signing path remains available without silently recording consent. |
| Prefilled date is left untouched | The displayed value is handled correctly in validation and the saved record. |
| An answer triggers a flag | Staff see the intended review state and know what action to take. |
| Connection is interrupted | The customer receives an understandable outcome and staff can check whether a submission exists. |
Only include minors, flags, or other optional features if they are part of the form you are publishing. Define the expected result before the test. Otherwise, it is easy to reinterpret whatever happened as acceptable.
For an interrupted submission, inspect the records before repeatedly pressing submit or starting again. Determine whether the first attempt completed. You are testing recovery and duplicate handling, not assuming an offline draft or retry feature works in every circumstance.
Test the phone and the keyboard
Use a real phone as well as a resized desktop window. On the phone, check whether the onscreen keyboard hides the next action, whether a long paragraph causes horizontal scrolling, and whether the signature control is usable without awkward zooming.
On desktop, move through the form using the keyboard. Follow focus through inputs, choices, date controls, and the submit action. It should be visible and predictable, with no control that traps the user. Check that error feedback can be found without relying solely on color.
These checks can reveal obvious barriers, but completing a short checklist does not establish formal accessibility conformance. For a more focused device pass, use the mobile waiver testing guide. If customers use a shared tablet, also test the reset between people so the next guest cannot see the previous guest's details.
Inspect the record, not just the success screen
After signing, find the result through the same route staff will use. Compare it with the test inputs. Verify the participant and guardian roles, answers, date, activity, and relevant form version. Open the generated PDF when available and check that long answers and agreement text are readable rather than clipped.
Confirm that a signing success does not automatically stand in for physical arrival. If you use waiver check-in, test that step separately with the resulting record. Staff should be able to distinguish a completed waiver from a checked-in participant.
The last-step testing guide is useful when the main concern is submission, confirmation, or retrieval. Keep a record reference in your QA notes so another authorized person can inspect the same result.
Decide what blocks publication
A missing agreement paragraph, a wrong person's record, lost required information, an unusable signing control, or a misleading success message should stop publication until resolved. A minor spacing preference can be tracked separately if it does not prevent reading or completing the form.
Give each failure an owner, an expected correction, and a retest result. When a fix changes a shared field or the signing flow, repeat the other paths that depend on it. Do not mark the form ready merely because the original symptom disappeared.
Keep the finished checklist with the tested version. If the wording, required fields, or family structure changes later, use that record to decide what needs retesting. A launch test is a useful baseline, not a permanent certificate that every future edit is safe.
Waiver testing questions
Is preview mode enough to test a waiver?
No. Preview helps with structure and appearance. You also need to test the public signing path, submission, confirmation, saved record, and any staff check-in steps.
Should I test with a real customer's information?
Use fictitious details and clearly identified internal records. Test data should not expose customer information or be confused with genuine participation. Follow your team's process for handling and cleaning up QA records.
Do I need to repeat every test after a small edit?
Match the retest to the change and its dependencies. A wording correction needs a content check. A change to a required field, shared control, signature, or minors section needs the affected signing paths tested again, including the saved result.