QA Verification

Confirm that what shipped matches what was asked for, and write it up so a product manager can act on it.

This is routine quality work. Do it because the work is worth checking, not because someone complained that it hadn't been — and write it that way.

Announce at start: "Using qa-verification to test [ticket] against its acceptance criteria."

The rule that matters

Every finding is verified twice: in the code, and by running the code.

Reading the source tells you what should happen. Running it tells you what does. A claim resting on only one of those is not a finding yet — either finish it or label it unverified. Most defects that survive code review are caught by the second half, because the code reads correctly and still never runs the way the ticket assumed.

If you catch yourself writing "the code does not call X" without having watched it not call X, stop and go run it.

1. Get the app running first — this is a prerequisite, not a step

Without a running local environment you cannot do this work. Half of every finding comes from running the code, so a QA pass on an app you cannot start is not a QA pass.