Test the flow. Know the boundary.

Define the layer you are testing

A visual inbox review answers a different question from a delivery test. You can inspect text wrapping, button feedback, navigation, and state transitions without sending mail. Verifying that an application submits a message requires an application environment. Verifying receipt requires a real receiving system under appropriate control.

Use a precise objective: a message should remain readable on a narrow screen; a copy control should report success accurately; an expiration view should explain what ended. Clear objectives prevent a convincing screenshot from being mistaken for evidence about untested layers.

Use fictional fixtures for visual review

Choose sample content with a purpose: a long subject, a wrapping sender name, a short confirmation, and several paragraphs of body text. Use obvious example addresses and fictional codes. Avoid introducing real customer messages merely to make a prototype look realistic.

The local inbox demo provides three fictional messages and the main interface states. It can be explored with a mouse, touch, or keyboard. It does not establish working mail delivery, production access control, or safe handling of arbitrary incoming HTML.

Review the edge cases deliberately

Test an empty inbox, a loading state, an open message, and the transition to expiration. Start a refresh and then create a new session. Check what happens when the timer is paused. Make sure the status, controls, countdown, and content still describe the same state.

Copy feedback should distinguish success from failure. Small-screen layouts should preserve readable addresses and reachable controls. A countdown should not repeatedly interrupt a screen reader with second-by-second announcements. These are functional requirements, not merely visual polish.

Keep live delivery within authorized scope

Use your own systems or an environment you have permission to test. Use a controlled receiving mailbox, fictional identities, and traffic appropriate to the test. Record what the application attempted and what the recipient system observed without assuming either result proves every stage worked.

For verification and recovery testing, use test accounts and avoid exposing real reset links or credentials in screenshots and shared issue reports. Respect address restrictions and rate limits. The verification guide covers the separate lifetimes and recovery concerns.

Produce evidence someone else can use

A useful report names the environment, viewport, fixture, action, expected result, and observed result. It also identifies the layers that remain untested. A front-end review can be complete while real delivery remains outside its scope.

Continue with the full responsible QA workflow for a step-by-step approach, then read the email architecture explanation to connect your test objective to the relevant part of the system.