Empty and error state UX testing checks whether an interface explains missing content correctly and gives someone a working next step. Start by controlling why the screen is empty. Then test the message, the recovery action, and the resulting state. A failed request must not pass as "No data yet."
A populated dashboard can hide these problems. Use the worksheet below to check a new account, an empty search, and a failed request separately. It is a proposed testing method with an illustrative example, not a report of customer results.
What is the difference between an empty state and an error state?
An empty state is a valid result with nothing to display, such as a new account with no reports or a search with no matches. An error state means an operation failed. If the request failed, the interface does not yet know whether there are records to show.
Stack Overflow's design system separates no-data and no-results cases and recommends an appropriate next action when the user can resolve the situation. When they cannot, it recommends setting expectations instead.[10] That distinction is useful for testing: a "Create report" button, a "Clear filters" button, and a "Try again" button address different causes.
Loading is another state. An unfinished request is neither a confirmed empty result nor a confirmed failure. If the interface keeps old content visible during a refresh, check whether it makes the pending or failed refresh clear.
Build a state matrix before running the test
Pick one screen and give each case a reproducible starting condition. A fixture is controlled test data or configuration that makes that condition repeatable. Your engineering team owns the fixtures, fault simulation, permissions, and reset process; this worksheet does not assume your browser-testing tool creates them.
Choose the cases your product actually supports. Mark the rest out of scope, not passed. For a broader release review, use the pre-launch UX checklist; keep this worksheet focused on state transitions.
How do you reach an error state safely?
Use an isolated test environment and a controlled fixture or mocked response. Do not break production, revoke a customer's access, or submit real payments to manufacture an error. If you cannot make the intended state reachable safely, record it as not exercised and ask the environment owner for a test case.
Playwright documents network interception and mocked API responses, including returning a chosen response without calling the real endpoint.[12] Those mocks apply to the browser context where they are installed. A mock in your local Playwright test will not automatically affect a separate hosted browser agent. Prepare a reachable test-only fixture for that agent, or keep the check in the local test harness.
For signed-in screens, follow the authenticated website testing guide. Use disposable accounts and synthetic records. Keep test controls out of production and record how the environment owner restores the starting state after each case.
Worked example: "No reports yet" after a failed request
Imagine a reporting app with two controlled responses for its report list:
- Case A: the read succeeds and returns an empty list.
- Case B: the read fails before the app receives a list.
These are illustrative cases, not a test we ran against a customer or Swarm. If both render "No reports yet. Create your first report," Case B is misleading. The app is asking someone to create data when it has not established that data is missing.
For Case A, test that the first-report action is available to the role and opens the intended creation flow. For Case B, test that the app acknowledges the loading failure and offers an appropriate recovery. Restore the read response, retry, and check that the known report appears without creating another report.
Use a task that describes the goal rather than naming the button you want clicked: "Find the saved quarterly report and open it. If it is unavailable, use the recovery offered on this screen. Do not create or delete reports." Keep the expected result in the reviewer record, separate from the task instructions.
A copyable case record:
Case: report-list read failure
Build and environment: [exact tested version, test-only URL]
Role: [disposable reader account]
Fixture: one known report; first list request fails
Task: find and open the saved report; use available recovery
Allowed actions: read, retry, navigate
Forbidden actions: create, delete, purchase, change permissions
Expected: failure explained; retry shows the existing report
Independent check: known report still exists; no new report created
Reset: restore normal response and disposable account state
Coverage: reached / blocked / not exercised
Result: expected behavior / defect / inconclusive
Evidence: [run, step, screenshot, and authorized readback reference]
"Reached" records coverage, not success. If login blocks the run before the report screen appears, record a blocked case. Do not turn an authentication failure into evidence that the report recovery works or fails.
Check what happens after recovery
The error message is only part of the test. Follow the next action through to its result.
- Preserved work: Check that a recoverable failure retains the input the person should not have to enter again. Do not retain sensitive values merely to satisfy this check.
- Correct destination: Confirm that retry, clear filters, or return navigation leads to the intended state, not another empty screen with the same label.
- Saved state: For a write, inspect the authorized application or backend record. A success toast alone does not prove persistence. When the write outcome is unknown, verify it before retrying; a repeated request could duplicate the action unless the application handles that case.
- Accessible feedback: Check the message with the relevant assistive technology as well as visually. W3C's status-message guidance covers changes such as search results, waiting, progress, and errors that can be presented without moving focus.[14] This is one accessibility check, not a conformance audit.
- Reset: Return the fixture to its documented starting condition before comparing another run. Otherwise the second run may test a different case.
Store failures as specific observations: "After clearing the filter, the seeded report remained hidden." Avoid conclusions such as "users will abandon the product" unless you have separate evidence about actual users.
Can AI test empty and error states?
A browser agent can attempt a task in an empty or error state when that state is reachable in its test environment. Its trace can show the message, attempted recovery, and visible result. It cannot establish customer comprehension, backend persistence, or accessibility conformance just by describing the screen.
Use Swarm for a bounded browser check after your team prepares the state. Swarm's AI personas produce synthetic observations, not participant testimony. Review the evidence and independently verify any consequential state change. Check current plans for access requirements before planning authenticated testing.
If the flow exists only as images, a screenshot review can examine the copy and visible sequence, but not whether retry works. When the question is whether people understand the recovery or trust the result, follow up with research involving real users.
Start with one screen where missing data and a failed load could look alike. Prepare both cases, run the same goal, and keep a separate result for each. Try that browser task in Swarm.
Sources
[10] https://stackoverflow.design/system/components/empty-states [12] https://playwright.dev/docs/mock [14] https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html