Full-Journey Visual QA

Full-Journey Visual QA reviews what changed across a complete product outcome, not just whether one isolated page still resembles a baseline. It binds every visual Observation to the Journey Version, declared context, step, source evidence, and functional result that produced it. A reviewer can then decide whether the change is intended, defective, nondeterministic, inaccessible, or blocked by incorrect state.

Pixel comparison remains useful. The difference is that pixels become evidence inside an outcome contract rather than the entire contract.

Why page snapshots lose product meaning

A screenshot can show that pixels changed, but the image alone cannot reliably answer:

• whether the user reached the intended outcome;
• which role, plan, data, locale, theme, viewport, clock, and flag state was active;
• whether the UI changed because the product changed or the rendering environment drifted;
• whether the changed control still has the correct accessible name and keyboard behavior;
• whether the baseline belonged to the current Journey Version;
• who accepted the change and what downstream content became stale.

Full-Journey review keeps those questions connected.

Start from checkpoints, not screenshot volume

Capture a visual Observation only where visual state helps prove or explain the outcome. A release-critical invitation Journey might need checkpoints for the invitation dialog, pending state, recipient acceptance, and resulting member state. Capturing every animation frame and intermediate loading state increases review work without necessarily adding confidence.

A useful checkpoint has:

1. a stable semantic purpose;
2. an expected functional consequence;
3. a declared State Capsule and context cell;
4. a deterministic capture policy;
5. relevant visual and accessibility evidence;
6. an owner and review consequence.

Declare comparison context

Only compare images that share a meaningful comparison context. Record at least:

• Journey and immutable version;
• context cell identity;
• viewport and device scale factor;
• browser and runner build;
• locale, timezone, theme, and reduced-motion state;
• font availability and loading completion;
• fixed or bounded clock policy;
• animation and transition policy;
• mask policy with an auditable reason;
• relevant data and feature-flag identity;
• baseline Observation and source Observation hashes.

If any dimension changes intentionally, decide whether the result belongs to a separate baseline rather than relaxing a threshold until everything passes.

Review seven useful views

No single visualization answers every review question. Reshot’s visual evidence contract supports review modes including side-by-side, overlay, blink, heatmap, DOM change, accessibility-tree change, and history.

View	Best question
Side-by-side	What does the reviewer perceive in each state?
Overlay	Did geometry, alignment, or cropping move?
Blink	Which large regions visibly alternate?
Heatmap	Where are pixel differences concentrated?
DOM change	Did structure or content explain the image change?
Accessibility-tree change	Did roles, names, states, or hierarchy change?
History	Is this new, recurring, or inherited from an earlier Decision?

A heatmap is evidence of difference, not evidence of defect. The Review Decision supplies intent.

Keep functional and accessibility evidence beside the image

Suppose the visual comparison is exact but the primary action no longer works. The Journey failed. Suppose the image changed because a button gained a more specific accessible name without a visual change. Accessibility meaning improved even though the pixels did not explain it. Suppose an axe finding appears only for the mobile dialog after a breakpoint alters focus order. The context and checkpoint matter.

Treat functional, visual, automated accessibility, manual accessibility, state, target, privacy, and policy evidence as peer records. Each record should point to the same timeline rather than being copied into disconnected dashboards.

Classify before updating a baseline

When a visual check fails, select a classification before any baseline changes:

• intended product change: the new state is correct and approved;
• product defect: the Journey outcome or intended presentation is wrong;
• state mismatch: the capture ran under the wrong actor, data, flag, locale, theme, or clock;
• target failure: the interaction resolved the wrong or missing element;
• nondeterministic rendering: animations, fonts, ads, time, randomness, or infrastructure altered the capture;
• accessibility barrier: semantic or interaction meaning failed even if the pixels are acceptable;
• privacy or policy failure: the artifact contains data that must not be retained or published.

Automatic baseline replacement erases this decision boundary. A new baseline should reference the approving Decision and the exact source Observation it supersedes.

Apply review authority explicitly

Not every actor should approve every subject. A product designer may decide an intended visual change. An accessibility owner may verify remediation or authorize a scoped, expiring exception. A release reviewer may block publication when downstream outputs are stale. The Decision record should identify the actor, authority, subject, evidence, rationale, outcome, and effective version.

When an exception expires or the Journey Version changes materially, reopen the affected review rather than keeping an inherited green state.

Connect outward consequences

An approved product change can invalidate screenshots in documentation, a support procedure, training media, an interactive demo, a marketing visual, or a release narrative. Full-Journey Visual QA records that impact while the evidence is still attributable.

This does not mean every screenshot automatically republishes. It means the system can identify affected Renditions and Publications, show their freshness state, and require an explicit refresh or accept-stale Decision through the supported path.

Adoption checklist

Begin with one visually meaningful Journey:

• choose three or fewer outcome checkpoints;
• declare representative contexts instead of a Cartesian explosion;
• run a determinism calibration before trusting diffs;
• retain functional and accessibility evidence at the same checkpoints;
• classify the first ten failures manually to expose state and target problems;
• require attributed approval for baseline changes;
• connect one approved Observation to one outward asset;
• measure review work, false-positive causes, and stale-output detection separately.

Use the Visual Test Readiness Checker before scaling. Read Playwright Visual Testing at Scale for runner-specific controls and the Visual Determinism Benchmark for a reproducible calibration harness.

Clarify the system boundary in Visual Regression vs Journey Verification.