QA Ultimate Stack
Set up a synthetic form test: fields, steps and test values
Read a live form's fields the way a screen reader does, build the steps, use obviously fake test values, check required fields without submitting, and set what the run must observe.
Fetch the fields from the live page
Start a new config with the form's URL and press Fetch fields. ODDVX opens the page read-only and lists every field, grouped by question rather than by input: "Are you a smoker?" is one required question with two options, not two unrelated radio buttons. It reads the form the way assistive technology does, so custom-styled radios, labels set with aria attributes and split date-of-birth boxes are understood correctly.
Fields hidden from visitors, such as honeypot traps for bots, are never offered. Each field keeps its label as well as a CSS selector, so if a redesign breaks the selector, the run can still find the field by what it says.
A table of fetched form questions with types, selectors and required flags, and a hidden honeypot field dimmed.
Build the steps
A config is an ordered list of steps. Each step fills its fields (text, select, checkbox or radio) and then clicks a button to move on. The last button step submits.
- Wait before a step for a URL to contain something or for an element to appear, so a step on the next page or behind a slow transition doesn't start typing too early.
- Success URL (for example /thank-you): after submitting, the run must reach a page whose URL contains it, or the form fails with a clear "the submit never landed" result.
- A final wait step after the submit makes the confirmation page an explicit stage of the journey.
A three-step flow: step one with fake test values, step two after waiting for the next section, then a wait step for the thank-you URL.
Use obviously fake test values
A real run submits the form, so the brand's systems receive it. Make every value obviously a test so it can be filtered out:
| Field | Value |
|---|---|
| Names | QA_TEST_DoNotAction |
| anything@qa-test.invalid (a reserved domain that can never receive mail) | |
| Phone | 0000000000 |
A table of test values for name, email and phone, each marked as filterable.
Check required fields without submitting
Before the first real run, press Check required fields. ODDVX fills your values, clicks submit with every outgoing request blocked, so nothing is sent, and reports what the page complained about, question by question. A phone number in the wrong format or an unset radio shows up here, not as a mysterious failed test later.
A required-fields check showing one complaint about the phone number format and a suggested fix.
Set what the run must observe
- Expected dataLayer events (required): each event the site should push, with the parameters that must be non-blank, such as form_start with form_name, or generate_lead with form_name and value.
- Expected tag / GA4 hits (optional): each GA4 event GTM should send, with its parameters.
- Expected first-party and third-party cookies (optional).
- Duplicate-fire check (optional): flags any event that fires more than once.
Each layer is explained in The three layers of a form test. Free keeps one saved form config.
A config form listing expected dataLayer events, an expected GA4 hit, two cookies and a success URL.
ODDVX for Windows
From the page to the hit, proved.
Start free with one saved form, one page and one parity check. Premium adds batch runs, exports and scheduled QA.