In this guide 6 sections
A complete checklist covers five areas. Requirements come with realistic test data, every role and integration gets its own pass, and named devices receive accessibility and performance checks. Defects carry evidence and an owner. A rehearsed rollback closes the list. Skipping one invites surprises.
Requirements, journeys and test data
Write the requirement down first. A tester cannot judge a release against a requirement that lives only in the product owner’s head, so each line should say who does what under which limit. For example, a branch manager can approve a purchase request under the branch’s monthly limit, and the test case should name the limit, the approver and the result.
Test data needs the same care. Build it from real shapes: a surname with an apostrophe, orders from one line to two hundred, a customer without an email address, and a zero-price product. Demo accounts hide all of it. Keep the data in a spreadsheet beside the checklist, with one column naming the rule each row exists to test, so a reviewer can see why every record exists.
Every role, validation rule and integration
Give each role its own pass. An admin, a branch manager and a front-desk user see different menus, different buttons and different records, so testing as the admin alone leaves most permissions unchecked. Try forbidden actions too. For instance, log in as the front-desk user and open the discount screen by typing its address directly, because hidden menu items are not the same as blocked permissions.
Validation rules need line items. Check that each form rejects a negative quantity, a duplicate invoice number or a date in the past, and does not silently truncate a long notes field. Integrations need them as well. Confirm that data sent to accounting software, a payment gateway or WhatsApp arrives intact with the right timezone, and that a plain message appears when the connection fails.
Devices, accessibility basics and performance under load
Name the devices in the checklist. List the two or three phone models and browser versions that most of your real users carry, taken from analytics or a staff survey, not from the tester’s desk. Record the exact versions in the checklist so every defect names the exact combination that produced it, even when the tester has since changed phones.
Accessibility basics fit on the same page. Check that the whole form works by tabbing through it with a keyboard alone, that text stays legible at default zoom, and that every field keeps a visible label. Run one journey with VoiceOver. Add one performance check. Open the busiest screen with a realistic volume of records and note whether it still responds within a few seconds on the slowest listed device.
Defects, evidence and acceptance decisions
Log defects so others can repeat them. Severity needs a shared meaning. Agree beforehand that a blocker stops billing, loses data or exposes another user’s records, while a cosmetic fault only needs a place in the next sprint. Record the steps taken, the data used, a screenshot or short recording, and a severity, because a defect mentioned only in a meeting is forgotten or fixed twice.
Name the reviewer too. Each defect needs a named person who decides whether it blocks the release, so acceptance becomes a recorded decision instead of something that happens because the deadline arrived.
Release and rollback readiness before go-live
Plan the way back. Test the release in an environment close enough to production to trust the results, then confirm someone can restore the previous version if a fault appears after launch. Release to one canary branch first. Run a post-deploy smoketest. Rollback beats a pressured hotfix.
A release without rollback is a bet. For most small business applications the preparation is modest: keep the previous build deployed and take a database backup immediately before release. Rehearse the restore once. Write the restore steps on one page, name who runs them, and note which customers must be told if the previous version is brought back. A rehearsed restore takes minutes, while an improvised one can consume a whole day of an engineer’s attention and a customer’s patience.
Release testing checklist
A five-section checklist covering requirements and data, roles and integrations, devices with accessibility and performance, defect records, and release and rollback readiness. Each section has a sign-off line for who verified it and when. Attach it to the release itself as evidence.
Open a blank worksheet to printQuestions owners ask
Who signs off test completion?
Sign-off belongs to whoever has the authority to accept the risk of shipping, usually the product owner or project lead, informed by what the testers found. Record it as a named, dated line. Silence is not approval.
What evidence should a testing report include?
It lists the journeys tested, the devices and environments used, and every defect with its severity and current status, so a reader can see exactly what was exercised. State what was left untested and why. That list is the release’s known blind spots.
Should the checklist change for small releases?
Keep all five sections but cut each down to the screens, roles and integrations the change actually touches, and never drop the rollback step. Small releases still break things.