How to test an AI-built app end to end before release

Start with the customer outcome, not the test inventory

Define one accepted journey from entry to a visible customer outcome. Give it a version, ordered steps and a final assertion so a later run cannot silently substitute a different path or screen.

Run the journey in a dedicated sandbox or staging account with disposable data. Record the target app credits, entitlements and human checkpoints required before the test begins.

Inspect the rendered product on desktop and mobile

A successful request and an overflow boolean do not prove the interface works. Capture the rendered routes and states at useful desktop, tablet and phone sizes, then inspect hierarchy, text size, contrast, target size, focus, reflow, errors and recovery.

• Treat tiny operational text, clipped labels and cramped controls as evidence, not polish requests.
• Exercise hover, focus, selected, disabled, loading, error and success states where they matter.
• Keep authenticated captures private and explicitly classified or redacted.

Make every specialist account for the whole assigned domain

Each councilor should return a complete subject-matter manifest: verified, observed, missing evidence or not applicable for every required dimension. Generic page links must not stand in for dimension-specific proof, and an all-not-applicable answer must not pass.

Zero findings is valid when the evidence supports it. Missing evidence remains a decision gap. The release decision must consume the audit manifest so a harmless informational finding cannot hide incomplete security, accessibility or operational coverage.

Fail closed and rerun the same evidence contract

Block protocol-relative navigation, destructive links, payments, sends, invitations and other consequential actions unless a human opens the exact gate. Bind each completed step to its path and screenshot hash, preserve raw evidence, and rerun after remediation against the same acceptance criteria.