Writing a browser test without a script still takes the same thinking: where the user starts, what they do and what should be true at the end. Plain English removes the selectors. It doesn't remove the need to be precise.
Describe one journey
Name the starting page and the account state, describe one independent journey, and finish with a result someone can see.
| Too vague | Easier to review |
|---|---|
| Test settings | Open account settings, change the display name to Release Tester and verify Release Tester is visible after saving |
| Check search | Search for "Notebook" and verify "Notebook" appears in the results |
| Make sure checkout works | Apply SPRING20 and verify "Discount applied" is shown and the total is $80.00 |
Avoid assertions like "everything looks right". They're hard to review, and they're hard for any tool to judge consistently.
Review the steps with someone who knows the requirement
In Zerocheck, a description becomes a list of steps you can read and edit:
version: zerocheck/v1
name: Display name can be changed
steps:
- Navigate to /settings/profile
- Enter "Release Tester" into "Display name"
- Click "Save"
- Verify text "Release Tester" is visible
Someone who understands the flow can write the description. Technical help may still be needed for credentials, fixtures and environment setup, since no-code doesn't mean no test data. Add the test-account setup separately and reference credentials by name.
Start in the web app, add code workflows when useful
Hosted testing needs no local install. Create a test or import a checklist in the web app, run it against a configured environment, edit the steps and save it. The CLI is optional, for localhost or an existing CI job, and Download YAML gives you a copy for your repository. Web tests stay editable in the web app; repository tests are edited in your repository.
Some workflows are outside browser steps altogether, including email, native apps and API-only tests, so plan those separately.