QA Checklist for Web Apps Before Release

A QA checklist for a web app release covers five areas, in this order: the features that changed and the paths people use most, the browsers and phones your users actually have, accessibility basics such as keyboard use and contrast, security basics such as who can see what, and page speed. Run it against the build that will ship, write down the result of every line, and file each failure as its own bug before anyone decides whether it blocks the release. The checklist below takes an hour or two for a small app. The filled example shows what a finished run looks like.

A checklist is not the same as a definition of done. The definition of done says when one task is finished; a QA checklist checks the whole release, where finished tasks meet each other for the first time.

Before you start

• Test the build that will ship, on an environment that matches production as closely as you can. A pass on a developer’s laptop is a different test.
• Have the list of what changed: the tasks in this release, and their release notes if they exist. The first section of the checklist is built from it.
• Prepare test accounts for each role: a new user, a normal user, an admin, and anyone with a restricted role. Most permission bugs only appear when you sign in as the wrong person.
• Decide in advance what blocks a release. Usually: data loss, a broken main path, a security hole or a blocked user group. Everything else is filed and scheduled.

1. Functional checks

Start with what changed, then the paths that pay the bills. For each changed feature, run its acceptance criteria as written, then try the edges: an empty field, a very long name, a double click on Submit, the back button halfway through a form. Then walk the main paths even if nobody touched them, because a shared component may have: sign up, sign in, password reset, the core action of the product, and checkout if there is one. Check that emails and notifications arrive and that their links work. Re-run the checks for any bug fixed in this release, and one or two around it; that is regression testing in a sentence.

2. Cross-browser and mobile checks

Test on the browsers your analytics show, not a list from a blog post. For most US consumer apps that means Chrome, Safari on iPhone, Edge and Firefox, but a business app used on managed Windows laptops may be almost all Edge. On phones, check a real iPhone and a real Android device if you can, because emulators miss keyboard covering, zoom and touch problems. Look for layout at narrow widths, tap targets that are hard to hit, forms where the right keyboard appears for email and number fields, and anything that depends on hover.

3. Accessibility basics

The standard to test against is the W3C’s WCAG 2.2↗ (opens in a new tab) at Level AA. The W3C advises using 2.2 for new work, and content that conforms to it also conforms to 2.0 and 2.1. Federal agencies work to Section 508, whose revised standards incorporate WCAG 2.0 Level AA, so a 2.2 AA pass covers its web criteria as well. Five checks are a sensible minimum for every release:

• Keyboard: every control can be reached and used with Tab, Enter and Space, focus is visible, and nothing traps focus.
• Focus not hidden: WCAG 2.2 added a rule that a focused element must not be entirely hidden, for example behind a sticky header or a cookie banner.
• Contrast: normal text at least 4.5:1 against its background.
• Target size: WCAG 2.2 asks for pointer targets of at least 24 by 24 CSS pixels, or enough spacing around smaller ones.
• Names and labels: images have text alternatives, form fields have labels, and error messages say what went wrong in words.

Run an automated scanner, then test by hand anyway. Section508.gov’s testing overview↗ (opens in a new tab) warns that automated tools cannot apply human subjectivity, so they either raise many false positives or, tuned to avoid them, test only a small portion of the requirements.

4. Security basics

A release checklist is not a penetration test, but a few checks catch the most common mistakes. The OWASP Top 10:2025↗ (opens in a new tab) puts Broken Access Control first, followed by Security Misconfiguration and Software Supply Chain Failures, and those three map directly onto release checks:

• Access control: signed in as a normal user, change an id in the URL or an API call to another user’s record. You should get a refusal, not their data. Try an admin page as a non-admin.
• Configuration: no debug pages, stack traces or test endpoints on the live site; cookies for sign-in marked Secure and HttpOnly; HTTPS everywhere.
• Dependencies: the package audit for this build is clean or every warning has a decision behind it.
• Inputs: forms reject script in text fields and files of the wrong type, and uploads have a size limit.
• Secrets: no keys or passwords in the front-end bundle, the page source or the repository.

5. Performance basics

Measure the pages that changed and the main landing pages against Google’s Core Web Vitals↗ (opens in a new tab) targets: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, judged at the 75th percentile of page loads on mobile and desktop. Lab tools give you a quick signal before release; real-user data after release tells you whether it held. Also check the obvious: no image several megabytes in size where a small one would do, and no page that fetches the same data three times.

The checklist

Release: [version]   Build: [id]   Environment: [staging / prod-like]
Tester: [name]       Date: [Month day, year]
Result per line: PASS / FAIL (bug ref) / N/A

FUNCTIONAL
[ ] Each changed feature passes its acceptance criteria
[ ] Edges: empty, very long, double submit, back button
[ ] Sign up, sign in, password reset, sign out
[ ] Core action of the product, start to finish
[ ] Checkout / payment in test mode (if any)
[ ] Emails and notifications arrive; links in them work
[ ] Bugs fixed in this release stay fixed

BROWSERS AND DEVICES
[ ] Chrome, Edge, Firefox (desktop), Safari (Mac)
[ ] Safari on iPhone, Chrome on Android, real devices
[ ] Narrow widths: no overflow, nothing cut off
[ ] Correct keyboard for email / number fields

ACCESSIBILITY (WCAG 2.2 AA basics)
[ ] Keyboard only: reach and use every control
[ ] Focus visible and not hidden behind sticky bars
[ ] Text contrast at least 4.5:1
[ ] Targets at least 24x24 CSS px or well spaced
[ ] Images have alt text; fields have labels
[ ] Automated scan run; results reviewed by a person

SECURITY
[ ] Another user's record by id: refused
[ ] Admin pages as non-admin: refused
[ ] No debug output, stack traces or test endpoints live
[ ] Sign-in cookies Secure + HttpOnly; HTTPS only
[ ] Dependency audit clean or each warning decided
[ ] No secrets in bundle, page source or repo

PERFORMANCE
[ ] LCP <= 2.5 s, INP <= 200 ms, CLS <= 0.1 on key pages
[ ] No oversized images; no duplicate data fetches

SIGN-OFF
[ ] Every FAIL has a bug ref and a blocks / does not block call
[ ] Blocking bugs fixed and re-tested, or release moved

A filled example

An invented booking app, release 3.4, which added a reschedule button. Only the lines with something to say are shown.

Release: 3.4   Build: 3.4.0-rc2   Environment: staging
Tester: Priya   Date: October 6, 2026

FUNCTIONAL
PASS  Reschedule: acceptance criteria 1-4
FAIL  Double click on "Reschedule" books two new slots     BUG-311
PASS  Sign up, sign in, reset, sign out

BROWSERS AND DEVICES
FAIL  Safari on iPhone: date picker opens under keyboard    BUG-312
PASS  Chrome, Edge, Firefox desktop

ACCESSIBILITY
FAIL  Reschedule dialog: focus goes behind the dialog       BUG-313
PASS  Contrast; labels; automated scan (2 warnings, reviewed)

SECURITY
PASS  /bookings/<other id> returns 404 for a normal user

PERFORMANCE
PASS  Booking page LCP 1.9 s, INP 120 ms, CLS 0.02

SIGN-OFF
BUG-311 blocks (duplicate bookings). BUG-312, BUG-313 do not
block; scheduled for 3.4.1. Release waits for BUG-311 re-test.

Filing what fails

Every FAIL line becomes one bug, written well enough that someone who was not there can reproduce it: steps, expected, actual, environment and evidence, as the bug report template lays out. Decide what blocks the release using severity and the team’s priority, which are not the same thing; bug severity vs priority explains the difference. Then add the fixed items to the release notes.

On fenbs, the quickest route from a finished checklist to the board is Add many, next to + New task. Paste one line per failure and start each with bug: so it is filed as a bug with a BUG- ref; indented lines under a Markdown list item become that task’s note, so the steps travel with it. Project, lane and priority are set once for the batch, and everything is previewed before anything is created. Priority runs 1 to 10, 1 the most urgent, so the release blocker can go in first at 1 and the rest at a lower urgency. When a fix is re-tested, its test status records Tested, Partly tested or Failed, with notes on what was checked, and filtering the board for tasks that are Completed but not tested is the question to ask before the next release.

- bug: Double click on Reschedule books two new slots
      Staging 3.4.0-rc2, Chrome 128. Open a booking, double click
      Reschedule, pick a slot. Expected one booking; got two.
- bug: iPhone Safari date picker opens under the keyboard
- bug: Reschedule dialog loses focus behind the overlay