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.
Give the reviewer a sequence, not an adjective
Pick one form your business relies on and try this check on a phone: open it, type, hide the keyboard, scroll, return, edit, then cancel before submitting anything. Use a safe test environment where available; do not create a real booking or contact a real person just to inspect the screen.
If you delegate the check to an AI worker, ask for the exact sequence tested, device or environment used, observed result, and what remains untested. Our earlier post on keeping preparation separate from permission to act explains that boundary.
“Looks good” describes a picture. “I can still see what I’m typing” describes work getting done.
If you want help defining practical checks for work you would hand to an AI team, tell us about the workflow.