Prove the outcome

A change is verified when another teammate can repeat the check and observe the expected behavior on the current code.

Start from the agreed outcome and use the smallest check that proves it. Exercise the relevant interface and observe its consequence. Include the failure cases the change could affect. A successful build is useful evidence, but it does not establish that a feature works.

Use the product for actual work as well as controlled checks. Repeated use reveals defaults you keep changing, unnecessary steps, interruptions and delays that accumulate across a task. Treat that friction as evidence for the next improvement.

Check the consequence

An operator changes their display name. The expected outcome is that the new name survives a reload. This illustrative browser test assumes an isolated, signed-in test account, reset to “Grace” before each run, and a profile page with the labels shown:

import { test, expect } from "@playwright/test";

test("the saved name survives a reload", async ({ page }) => {
  await page.goto("/settings/profile");
  await expect(page.getByLabel("Display name")).toHaveValue("Grace");
  await page.getByLabel("Display name").fill("Ada");
  await page.getByRole("button", { name: "Save", exact: true }).click();
  await expect(page.getByRole("status")).toHaveText("Name saved");

  await page.reload();
  await expect(page.getByLabel("Display name")).toHaveValue("Ada");
});

The reload checks more than the success message. Whether it proves database persistence depends on the environment: an in-memory fixture only proves behavior against that fixture. A live integration needs evidence from the integration itself.

Make the demo prove the claim

Keep each demonstration focused on one claim. Show the starting state, perform the action, then show its consequence. A persistence demo reopens the saved work. An export demo inspects the file’s contents. A permission demo attempts the forbidden write and shows both the refusal and the unchanged data. A speed demo shows the measurement and its conditions.

Use a workload representative of actual use. Identify simulated data, unfinished behavior and limits that affect the claim. Keep the relevant inputs and results visible; explain the design decision briefly. The viewer should be able to see the evidence and understand how to repeat it.

Keep proof repeatable

Use existing tests and tools first. For a bug, reproduce the failure before fixing it when practical, then rerun the check. Keep a regression test when it will catch the defect again without excessive setup or brittle mocks.

Run the product’s required checks. After further edits, rerun the checks affected by those edits. Review whether they cover the intended behavior; green results cannot tell you that you chose the right assertions.

Each product owns its verification commands, fixtures and necessary setup. Keep useful instructions with the product. A verification skill is worthwhile when it helps the next person repeat a difficult check. It is not a requirement for a simple product.

Report what you checked, how to repeat it, and what remains unverified. Link useful evidence without creating a report for its own sake.

Finish cleanly

Cleanup is part of completing a change. Remove the code, dependencies, flags and documentation the change makes obsolete. Resolve temporary workarounds introduced during the task, or state clearly what remains and why. Keep this within the change’s scope; preserve unrelated work and useful regression tests.

Stop the servers, browsers, watchers and workers you started, including their child processes. Track ownership when launching them, then verify they have exited and released their ports. Do not stop another session’s processes. A preview may stay open for active user testing if its owner and purpose are clear; close it when that testing ends.

Remove disposable scripts, logs, frame dumps, captures and test data you created. Retain only evidence useful for review or reproduction, in a known location with a clear reason to keep it. An ignored folder is still clutter if nothing needs its contents. Report any cleanup that could not be completed.

The effort should fit the change. The outcome and the proof matter more than the ceremony used to produce them.