Check a web release through real customer journeys
Exercise the application in a browser to catch broken navigation, forms, missing assets, and layout problems before customers encounter them. Cover desktop and mobile behavior.
How this works
Exercise the application in a browser to catch broken navigation, forms, missing assets, and layout problems before customers encounter them. Cover desktop and mobile behavior. Use this before a web release to exercise the paths customers rely on. A build passing does not establish that navigation, forms, responsive layouts and failure states work in a browser.
Define a bounded journey matrix against a known build and use test accounts or isolated data for state-changing actions. Record observable steps, requests and visible outcomes. Report verified failures with reproducible evidence and distinguish untested coverage from passing behavior.
Before you start
Test target
Confirm the build, environment and permitted test accounts.
Journey matrix
Select critical user flows and expected outcomes for desktop and mobile.
Test-data rules
Define disposable records and cleanup limits for actions that create or change data.
Prepare the inputs
- base_url
- Required
authorized test URL and build identifier
Avoid accidentally exercising production mutations.
- journeys
- Required
preconditions, actions and expected results
Include relevant empty, loading and error states.
- viewport_matrix
- Required
supported widths and browsers
State what is covered rather than imply all platforms.
- test_credentials
- Required
approved account references
Keep secrets out of screenshots and reports.
Implementation, step by step
Establish the environment
- Confirm the build and account state before testing.
- Check page health and record initial console or network errors.
Checkpoint: A reproducible starting state exists.
Exercise core journeys
- Follow the agreed paths through navigation, search, forms and pagination.
- Verify visible outcomes and resulting records rather than relying on a successful click.
Checkpoint: Each journey has an observed result.
Inspect responsive behavior
- Repeat relevant flows at supported small and large viewports.
- Check overflow, focus order, controls and content visibility.
Checkpoint: Layout and interaction evidence is captured.
Test failure states
- Use bounded invalid input or available simulated errors to inspect recovery.
- Do not perform destructive or uncontrolled fault injection on live systems.
Checkpoint: The relevant error behavior is documented.
Report and retest
- Write failures with exact steps, expected versus actual behavior and screenshots.
- After a fix, repeat the affected journey and nearby regression checks.
Checkpoint: The report separates pass, fail, blocked and untested.
Decisions along the way
A flow sends a real message or payment
Use a test mode or stop before the irreversible step unless explicitly authorized.
Failure is intermittent
Record frequency and conditions without declaring a deterministic root cause.
Test account lacks permission
Mark coverage blocked rather than call the feature broken.
What you will produce
web-journey-report.md
MarkdownA release review with reproducible findings.
Include: build · journey · status · steps · expected · actual · evidence
journey-coverage.csv
CSVAn explicit record of tested and untested combinations.
Include: journey · viewport · browser · state · result
Check the result
- Verify the tested build matches the intended release candidate.
- Confirm successful flows reached their actual end state.
- Ensure failures can be reproduced from the written steps.
- Inspect screenshots for secrets and unrelated customer data.
When something goes wrong
Environment becomes unavailable
Preserve completed evidence and mark remaining coverage blocked.
Automation selector breaks
Inspect the UI and distinguish test-script drift from a product defect.
Test data persists unexpectedly
Stop further creation and follow the agreed cleanup process.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: test a saved-search journey.
Inputs
Build B7 allows a test user to search, save a filter and reload. On desktop the filter survives; at 390 pixels the save button is hidden by overflow.
Expected result
Synthetic result: desktop flow passes; mobile flow fails with viewport and screenshot evidence. Do not mark all mobile functionality broken or the release fully verified.
Run a small pilot
Start small
Test three critical journeys on one release candidate and two viewports.
Record the baseline
Record manual test duration and defects previously missed.
Agree success criteria
Agree coverage and failure-severity criteria before using the report for release review.
Stop or revise
Stop state-changing tests if the environment or account is not isolated as expected.
Keep the scope clear
- Testing cannot authorize deployment or production data changes.
- Passing selected journeys establishes only the documented coverage.
Check before using
A tester confirms failures and coverage. Use an isolated test environment for actions that create or change data.
Business activities
- Build and change software
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Release URL and intended user journeys · Test accounts and safe sample data
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow