Map application surfaces before testing them

A test plan built from page names alone misses the states where software usually fails: empty results, expired sessions, partial permissions, invalid input, interrupted uploads, and recovery after errors. A surface catalog makes those states visible before anyone claims coverage.

Start with applicability

Give every surface a stable ID and decide whether it is required, conditional, not applicable, or still unknown for this application. “Not applicable” needs a rationale. It should never be a quiet way to remove a difficult test.

Useful surface families include:

• entry and navigation;
• authentication, authorization, and session recovery;
• loading, empty, error, and success states;
• create, edit, delete, import, and export flows;
• keyboard, focus, reduced motion, and responsive layout;
• audit, observability, failure recovery, and data retention; and
• administrative or destructive operations.

The catalog is a question set, not a mandate that every product implement every feature.

Keep three dimensions separate

For each applicable surface, record:

1. Applicability: does this product need it?
2. Implementation: not started, planned, draft, prototype, implemented, or retired.
3. Verification: not run, partial, passed, failed, blocked, or not applicable.

An implemented surface can still be unverified. A prototype can pass its own narrow checks without being production-ready. A passed check needs an evidence reference; the word “passed” is not evidence by itself.

Write an observable check

Tie each check to a surface ID and describe the precondition, action, expected result, environment, and evidence to retain. For example, a password-reset surface might require a valid request, an expired-link case, a non-enumerating response, keyboard focus behavior, and recovery after the link is used. If the application has no accounts, mark the surface not applicable and explain why.

Review gaps without inflating coverage

Summarize required surfaces by implementation and verification state. Treat unknown applicability, blocked verification, and missing evidence as work queues. Do not convert a screenshot, generated test, or broad end-to-end pass into coverage for states it did not exercise.

This approach is intentionally tool-neutral. The catalog can live in JSON, a spreadsheet, a test-management system, or code as long as stable IDs and independent states survive the move.

Download a synthetic starter

The JSON template and CSV template contain the same five fictional records. Every example is explicitly synthetic; all applicable verification states are not-run, so the templates claim no executed test or real application coverage. An empty evidenceRefs array or blank evidenceRefs cell means no evidence has been recorded and must never be interpreted as passed.