Guide · Free checklist

Pre-launch QA checklist for small software teams

The checks we run in a launch-readiness review, written so your own team can run them before launch. Tick them off in the browser or print the page. No email needed.

By Thomas Wagenberg, founder of Wagenberg Technology Group. It is the method behind our sample launch-readiness report, an application we built with invented data. It is general guidance, not a record of client results, and it does not replace a security test.

1. Before you start testing

Testing without a written scope finds whatever it happens to find. Agree these first.

Every user role is listed, for example admin, staff and customer, with what each one may and may not do.
The devices and browsers that matter are named, including at least one phone width.
The features in scope, and the ones out of scope, are written down.
A staging environment exists, separate from production, with a test account for every role.
Test data is invented. No real customer records are copied into staging.
Everyone agrees the severity levels (section 7) before the first defect is filed.
One person is named who decides whether the release ships.

2. Roles and permissions

Permission mistakes are the defects that show the wrong data to the wrong person. Test them on the server, not only on the screen.

Each role can complete its main task end to end.
Each action a role must not take is refused by the server when called directly, not only hidden on the screen. In our sample report, the buttons were hidden correctly while the server still allowed the action; only direct calls caught it.
Changing a record ID in the address or the request does not show another user’s record.
Deactivated accounts cannot sign in, and signing out ends the session on the server.
Administrators cannot lock themselves out, for example by removing their own admin role.
Every decision the business relies on, such as approve and reject, is written to the audit trail, for each decision type.

3. Desktop and phone

Run the main task for each role at desktop width and at a phone width.

No sideways scrolling at phone width, on every screen a role uses.
Buttons and links are large enough to tap, and nothing important sits off screen.
Every visible form control has a label.
The keyboard alone can complete the main task: a sensible Tab order, Enter submits, and focus is visible.
Error messages say what went wrong and how to fix it, next to the field.

4. Input and data

Check what the product accepts and what it saves.

Required fields, formats and lengths are checked on the server, not only in the browser.
Text that contains HTML or script is shown as text, never run.
Duplicates, empty values and very long values are handled on purpose.
A failed save tells the user, and nothing they typed is lost.

5. If your product books time or syncs calendars

Scheduling code often looks fine in a demo and breaks at the edges.

Bookings made across a daylight saving change land at the right time.
A booker and a host in different time zones see the same slot correctly.
Two people trying to book the same slot at the same moment cannot both succeed.
Shown availability matches the person’s own connected calendar, including blocked time and buffers.
Reschedule and cancel work for every role that can use them.
Calendar sync and any calendar feed you publish work in more than one calendar app.
Automated tests cover the scheduling logic, so the next change is less risky.

6. If your product uses AI to create records or draft messages

AI output can read well and still be wrong.

A sample of real outputs is read against the source data it came from.
Each error is logged with an example, and recurring patterns are grouped.
Fields with a fixed shape, such as totals, IDs, dates or allowed values, are checked by a rule in code before they are saved or sent.
After a prompt or rule change, the same examples are rerun, so you can see what moved.
When the model is wrong, slow or unavailable, the failure is logged and someone is told.
Passwords, API keys and bulk data never go into AI tools.

7. Before you ship

The launch decision should be made with everything known in front of you.

Every defect is a ticket with steps to reproduce, the expected and actual result, and a severity level.
Severity uses four levels. Critical: a role can do or see what it must not, records can be lost, or a core task is blocked for everyone. High: a control the business relies on, such as the audit trail, is wrong, or a core task fails for a whole role. Medium: something fails for some users, devices or inputs and a workaround exists. Low: cosmetic, with no effect on data, permissions or task completion.
Every fix is retested against its original ticket, and a fix that only partly works is logged again rather than closed.
A list of open defects at launch time is written down, with who accepted each one.
Critical defects should be fixed before release, and any High defect that ships is accepted in writing by the person who decides.

Ticks are not saved; the page stores nothing. To keep a copy, print the page or save it as a PDF from your browser.

Want us to run it for you?

We run these checks on your staging environment, file each defect as a ticket, fix the ones you assign to us as reviewed pull requests, and retest every fix.

Launch-readiness review: every role, desktop and phone.
Calendar and scheduling audit: section 5 in depth, then the fixes.
AI data and output review: section 6 in depth.

Request a launch-readiness review or email thomas@wagenbergtech.com