Yesterday, an iPhone keyboard covered the very thing someone needed to type into: Chief’s invitation form. The report was specific—the email input disappeared when the keyboard opened. The form existed. The useful part had left the screen.
That is a better starting point for testing mobile forms than a screenshot of a tidy, empty page.
A business owner has a version of this problem whenever work moves from a desk to a phone. An appointment request, a job note, an invitation to a colleague: the form has to work while someone is actually using it, not just while someone is admiring the layout.
The keyboard is part of that use. So is editing a mistake halfway through an address. So is reaching the bottom of a long form without losing your place.
Test mobile forms in the awkward state
Forge prepared a change to Chief’s shared mobile sheet layout, letting a tall form shrink into the space above the keyboard and adding room below the top edge of the screen. The invitation logic was left unchanged.
The more reusable artifact is the regression flow alongside that change. It opens the invitation form, focuses the email field, types a test address, checks that the field and controls remain visible, hides the keyboard, scrolls through a long form, returns to the field, edits the address, and cancels. It never sends an invitation.
The accompanying test instructions go further: paste multiple addresses, move the cursor to the beginning and end, and check typing there. Try the optional note. Check a small iPhone, a larger device, and Android. Make sure hiding the keyboard restores the layout.
That turns “make the form better” into actions a reviewer can repeat.
There is an important limit to this result. As of this morning, the code change is in an open pull request, not merged. Forge reports passing typechecks, lint and unit tests, but native keyboard testing remains pending because simulator or device tooling was unavailable. A written test flow is not a successful device test, and neither proves a released fix.
Make the check a recurring responsibility
Pick one mobile form your business relies on. Give one person responsibility for checking it before each release that changes the form, its surrounding layout, or keyboard behavior. The recurring job is not “make it look good.” It is “show what was tested before we call this ready.”
Here is a brief you can reuse:
Before each relevant release, check this form in a safe test environment: open it, type, hide the keyboard, scroll, return, edit, then cancel. Do not submit, send invitations, or create bookings. Record the device or environment, the exact sequence, whether the field and controls stayed visible, and anything you could not test. Flag hidden controls or incomplete coverage to the person deciding whether to release.
An AI worker can prepare the checklist and collect the results. It should only report a device check as passed when it has evidence from that device or a suitable test environment. If it cannot run the check, its handoff is “device check pending,” with the remaining steps for a person—not “looks good.”
Our earlier post on keeping preparation separate from permission to act explains that boundary. The check does not authorize sending anything or releasing a change.
“Looks good” describes a picture. A named owner, a repeat trigger and an observed result make this a responsibility you can hand off again.
If you want help defining one recurring check for your business and the evidence an AI team should return, tell us about the workflow.