Hiring form test cases are the visible half of a recruitment system’s quality, and the half most often written from the happy path outward. A form that works when a candidate fills every field correctly is not tested; it is merely observed once.
This article sets out why multi-step forms hide defects between their steps, which applicant branches deserve a dedicated case each, how required fields move as answers change, and what happens when the same person submits twice.
Why do multi-step forms hide so many defects?
Because each step is checked on its own. A single-page form is usually tested end to end, since the whole interaction takes a minute. A form split across five steps is usually tested one step at a time, by the same person, in the same session, starting from a state that the previous step conveniently left behind.
The defects that survive live in the seams. A value entered on step two and read on step four. A validation rule that runs when a step is left but not when the form is resumed at that step. A field that is required in one direction of travel and silently optional in the other. A back button that discards the step’s contents or, worse, keeps the old values and writes them back over the new ones.
Two habits find most of them. Travel the form in an unexpected order, including backwards, and confirm that values survive the journey intact. And begin each case at the step under test with a state constructed directly, rather than by replaying the earlier steps — because replaying them means the earlier steps are implicitly part of every case, and a defect there will make every case fail for the same reason and hide the rest.
Which applicant branches deserve their own test case?
At least four, because each one exercises a different set of conditional fields.
| Branch | What it stresses |
|---|---|
| First-time applicant with no experience | Sections that must be skippable, and a submission that remains valid when they are empty |
| Experienced applicant with a long history | Repeated entries, ordering, and whether previous entries are editable after more are added |
| Applicant with no formal education | Required-field rules that assume education exists, and the messaging that appears instead |
| Applicant from another region | Date formats, name order, address structure, and any field whose validation is region-shaped |
A fifth branch is worth adding in most systems: the applicant who starts, leaves, and returns much later. That case is not about content at all. It is about whether the partial state is preserved, expired, or accepted and submitted as if complete.
The four branches interact with each other, and the interactions are where coverage silently thins out. A long history submitted from another region combines repeated entries with foreign date ordering. An applicant with no education who also has no experience must be allowed to reach submission without inventing content to get there. Testing the branches separately is necessary and not sufficient; a small number of combination cases catches the rest.
How do required fields change with the answers given?
They change constantly, and the rule that governs them is a dependency rather than a static list.
A field is required because of something answered earlier, and that dependency usually runs across two or three steps rather than within one. Declaring a licence makes the licence number required and the issuer required with it. Selecting a country changes which address fields are mandatory and which are not offered at all. Choosing that experience exists makes the whole experience section required, including the specific subfields that describe it.
Three failure modes follow from dependencies. The first is a rule that is only applied forwards: the applicant selects the option that makes a field required, steps past it, goes back and deselects the option, and the now-irrelevant field is still enforced. The second is a rule evaluated at the wrong moment, so the requirement is checked when the step is displayed but not when it is submitted, or the reverse. The third is a rule that cannot be satisfied at all, where the form demands a value in a field it has just hidden.
Testing these properly means writing cases as pairs of a selection and its expected consequence, rather than as a list of fields to fill. The question each case answers is not whether a field validates but whether the form’s requirements match the answers given so far.
What should happen on a repeat submission?
The honest answer for a candidate’s experience is that a second submission should be either clearly recognised as a duplicate or clearly treated as a new application, and never quietly produce a third state that nobody designed.
Four situations get conflated, and each needs its own expected behaviour. A double click on submit while the first request is still in flight, which should produce one application. A refresh of the confirmation page, which should not resubmit. A deliberate second application for the same role after a first one was submitted, which is a product decision and should be an explicit one. And a resumption of a draft that was already submitted, which should not be possible.
Draft behaviour deserves the same treatment. A saved draft is a partial record, and the rules about how long it lives, when it is refreshed and what happens to it when the applicant never returns are all decisions the operator makes rather than laws. What a test can insist on is that the behaviour is consistent and that the applicant is told about it.
For developers: constructing form state
Build each case from a named state rather than from a sequence of clicks. A case that says the applicant has a completed education section and is on the experience step should set that state directly, so the case tests the step and nothing else.
Four practices make the suite maintainable. Name cases after the condition they exercise, not after the step they run on, because the step number changes whenever the form is redesigned. Keep the filler content obviously synthetic — placeholder names and clearly fabricated employers — so that no case can be mistaken for a real person’s data. Keep the minimum viable submission in one place, so that adding a required field is a one-line change rather than an edit to every case. And keep validation messages out of the assertions where possible, since wording changes far more often than behaviour and a suite that fails on copy is a suite people stop reading.
The content used in these cases should be placeholder text throughout. Never seed a hiring form test with a real candidate’s information, even in a safe environment, because that information then exists somewhere it was never meant to go. The examples on this site are constructed for exactly this purpose.
Next steps
Take the four applicant branches and check whether each has a case that reaches submission. The branch that usually has none is the applicant with no education and no experience, and it is the one most likely to be broken, because it is the one the team never fills in by hand. How the parsed documents behind a shortlisting flow are built is covered in resume parsing fixtures, and the date rules that a region-shaped form usually gets wrong are set out in employment history timelines. The career profile tool is where to generate a record when a case needs a plausible applicant behind it.