The QA Sign-Off Checklist: 12 Things to Verify Before You Merge
A practical QA sign-off checklist covering 12 things to verify before you merge—functionality, edge cases, regressions, security, and workflow state.
“It works on my machine” is not a sign-off. A proper QA sign-off checklist is what stands between a pull request and a production incident—a repeatable list that catches the gaps a quick glance always misses. The twelve checks below cover functionality, edge cases, regressions, and the workflow hygiene that keeps your team’s board honest. Run them before you click merge, every time.
Why a checklist beats intuition
Experienced reviewers still miss things, because human attention is inconsistent and PRs are tiring. A checklist isn’t an insult to your judgment—it’s a safety net that makes your judgment reliable under pressure. Keep it visible on every PR and treat skipping an item as a deliberate, recorded decision rather than an accident.
1. The acceptance criteria are actually met
Reread the issue. Does the change do what was asked—all of it, not most of it? A PR that solves 80% of the ticket and silently drops the rest is a future bug report. Match the diff against the stated criteria line by line before anything else.
2. The happy path works end to end
Run the primary user flow yourself against a real deployment, not just the test suite. Per-PR preview environments make this cheap—spin one up, click through the feature as a user would, and confirm the obvious case behaves. Passing unit tests prove logic; clicking through proves experience.
3. Edge cases and boundaries are handled
Empty states, zero, maximum lengths, the very first record, and the very last one. Most defects hide at the edges, not the center. Probe the inputs nobody thinks about: blank fields, enormous values, special characters, and concurrent actions.
4. Error and failure paths degrade gracefully
Force the failures. Disconnect the network, feed bad input, hit a missing record. The feature should fail with a clear, non-leaking message rather than a stack trace or a blank screen. Verify that errors are surfaced to the user and logged for the team.
5. No regressions in adjacent features
A change rarely lives alone. Touch the areas that share code or data with this PR and confirm they still work. Regression is the most expensive bug class precisely because it ships unnoticed—so test the neighborhood, not just the new room.
6. Security basics hold up
Check the obvious surfaces: is user input validated, are queries parameterized, is output escaped, and does the change respect existing permissions? A reviewer reading the diff can catch unescaped input or a missing authorization check faster than any scanner. Treat anything touching auth, input, or data access as a mandatory deeper look.
7. Performance hasn’t quietly regressed
Watch for the silent killers: an N+1 query, an unbounded list, a missing index, a synchronous call in a hot loop. You don’t need a load test for every PR—just confirm the change doesn’t turn one query into a hundred or one request into a timeout.
8. Tests exist and genuinely cover the change
New behavior needs new tests, and those tests must fail without the change. Skim the test diff: does it assert the actual requirement, or does it just exercise code without checking outcomes? Coverage that doesn’t assert anything is theater.
9. The workflow state is correct
This is the one teams forget. After your manual pass, the PR’s status should reflect reality: move it from in_progress to passed (or failed) so the board tells the truth. When workflow states map to GitHub labels and sync automatically, a single status change keeps the dashboard, the label, and the PR aligned—no stale “in testing” cards lingering for days.
10. Documentation and changelog are updated
If the change alters behavior, a setting, or an API, the docs must move with it. Out-of-date documentation is a slow-acting bug that costs every future reader. Confirm READMEs, inline comments, and any user-facing notes match the new reality.
11. No debug artifacts or secrets slipped in
Scan for leftover console.log, commented-out code, hardcoded credentials, test tokens, or local URLs. These are the small embarrassments that make it to production. A quick search of the diff catches almost all of them before they become a security write-up.
12. The result is recorded, not just remembered
Sign-off only counts if it’s traceable. Post your verdict back to the PR—what you tested, what passed, what you couldn’t cover—so the decision has an owner and an audit trail. Recording results as you go also means your testing time and outcomes feed into reports, turning each sign-off into data instead of a fading memory.
Making the checklist stick
A checklist nobody follows is worse than none, because it creates false confidence. Embed it where the work happens: as a PR template, a saved comment, or a set of test cases attached to the pull request. The goal is that completing the list is the path of least resistance, not an extra chore. When QA test cases live alongside the PR and results are recorded in one click, the checklist stops being paperwork and becomes the workflow.
Key takeaways
Merging without a sign-off ritual is how regressions and incidents get in. Verify acceptance criteria, the happy path, edge cases, failure modes, regressions, security, and performance—then update the workflow state, docs, and record your result. Twelve checks, run consistently, prevent far more pain than they cost.
If you’d like your sign-off to leave a trail—test cases on the PR, results recorded, and the workflow label synced back to GitHub automatically—KazTrack is built to make that the default rather than the exception.