SCENARIO GUIDE · FORM TESTING

Agent Browser Form Testing: A Safe Smoke-Check Workflow

A form can accept clicks and still lose data, skip validation, or leave the user unsure what happened. This smoke-check workflow keeps an Agent browser run small, observable, and safe to repeat.

Published ORIGINAL · SOURCE-AWARE
01

1. Write the form contract

Name each field you will touch, the valid and invalid examples, the submit action, and the final state that counts as success. A useful contract says what appears after submission, not merely that the button became disabled.

Use synthetic values and an isolated environment. If the form requires a real account, personal identifier, or production record, the task is no longer a harmless smoke check and needs a different approval boundary.

  • Every field has a harmless test value.
  • At least one invalid case is defined.
  • Success and failure states are visible and named.
  • The environment and rollback path are explicit.
02

2. Choose the smallest browser role

agent-browser is a practical choice for a short, interactive browser run. browser-use can be portable when the page and final state are clearly defined. When the run becomes a regression check, playwright-workflows or webapp-testing is a better evidence layer because the steps and assertions can be repeated.

Do not ask a browser Skill to infer approval. A successful navigation is not permission to submit a message, create a record, or reveal a credential.

03

3. Assert the final state

Check the field values, inline error text, focus location, disabled or enabled state, confirmation message, and any created test record. Save a screenshot or browser log only when it helps another reviewer verify the claim; do not collect more data than the check needs.

Repeat once from a clean browser state. If the result changes, record the dependency—cached data, login state, timing, or an unstable selector—instead of hiding it behind a green result.

  • The expected field values are still present at submit time.
  • Invalid input is rejected for the intended reason.
  • The final message or record is verified, not assumed.
  • A second clean run has the same outcome or explains its variance.
04

4. Stop before side effects

A form test becomes consequential when it sends a real message, publishes public content, changes an account, charges money, deletes a record, or uploads personal data. Treat those transitions as hard stops and ask the owner to take over at the final step.

The article's useful promise is therefore modest: it proves one form contract in one approved environment. It does not certify the entire application, every browser, or the safety of the underlying business process.

NEXT STEP

Make one form outcome observable

Use safe data, a named final state, and a repeatable browser check before expanding the flow.