Loading WURK...
AnyTest
AnyTest
AnyTest (anytest.dev): AI testing agents that explore your web app from a URL, write end-to-end tests and report what breaks. Agents test, you review.

A 20-minute pre-launch QA checklist for your web app

The signup, the login, the paid flow, the same on a phone, console errors and links: a 20-minute manual QA pass that catches the bugs users hit first.

Published on October 20, 20266 min read

A pre-launch QA checklist is a short, fixed list of things to try on your web app before real users do: the signup, the login, the one action you charge for, the pages on a phone, and the errors in the browser console. Done by hand it takes about 20 minutes. This article is that list, in the order that catches the most expensive bugs first, plus what to do when you do not have 20 minutes.

Why 20 minutes is enough for a first pass

Most launch-day bugs are not subtle. They are a confirmation email that never arrives, a button that sits under a cookie banner on a phone, a checkout that returns a 500 when a coupon is applied. These show up the first time anyone walks the main flows on a clean browser. A full test suite is better, and automated web QA from AnyTest builds one for you, but a first pass by hand is still worth doing today.

Two rules before you start:

  1. Use a fresh browser profile or a private window. Your own session has cookies, saved logins and cached assets that hide problems.
  2. Write every failure down as you go, with the URL and what you clicked. You will forget the third one by the time you find the fifth.

The checklist, step by step

1. Signup (4 minutes)

  1. Create an account with a new email address. Use a real inbox you can read, since the point is to see the email arrive.
  2. Check the confirmation email: does it arrive, is it in spam, does the link work, does the link work a second time (it should not, or it should say so clearly)?
  3. Try a bad input: a password that is too short, an email with a typo. The form should explain what is wrong, in words a person understands.
  4. Try the same email twice. The second signup should fail with a clear message, not a blank page.

2. Login and logout (2 minutes)

  1. Log out, then log in with the account you just made.
  2. Try a wrong password once. Then the right one. You should land where a returning user expects to land, not on a blank dashboard.
  3. Open the password reset flow. Request the email, use the link, set a new password, log in with it. Reset links are the most common broken flow we see, because nobody tests them after the first week.

3. The one thing you charge for (5 minutes)

Walk the flow that makes money: the checkout, the upgrade button, the booking form. Use a test card or a test mode if your payment provider has one.

  1. Add the item, apply a coupon if you have coupons, go to the last step before paying.
  2. Change something late: the quantity, the plan, the billing country. Prices and totals should update without a reload.
  3. Complete the payment in test mode. Check the receipt email and what the app shows right after. A payment that succeeds while the app shows an error costs you a refund and a support ticket.

4. The same three flows on a phone (4 minutes)

Do not use the browser's device emulator for this. Use a real phone on mobile data, or at least on Wi-Fi with the laptop closed.

  1. Open the home page. Can you read it without zooming? Does the main button fit on the screen?
  2. Repeat signup and the paid flow. Watch for fixed banners (cookie notices, chat widgets) covering buttons, and for inputs that open the wrong keyboard (a number keyboard for an email field).
  3. Rotate the phone once. Layouts that only work in portrait are common.

5. The browser console (2 minutes)

Open the developer tools on your laptop (F12 in most browsers), switch to the Console tab, and reload the home page, the dashboard and the checkout. Red lines are errors. Some are harmless; a repeating TypeError on every page is usually a feature silently not working. Also check the Network tab for requests in red: a failing analytics call is fine, a failing /api/orders call is not.

6. Links, images, 404s (3 minutes)

Click every link in the header and footer. Open the pricing page, the terms, the privacy policy, the blog if you have one. Look for broken images and for pages that still say "Lorem ipsum" or "Coming soon". If you have more than 30 pages, a crawler will do this faster than you; the manual pass still catches the ones that matter most.

What to do with what you found

Sort the list into three piles:

  • Blocks launch: a user cannot sign up, log in or pay. Fix today.
  • Costs money or trust: a wrong total, a broken reset link, a form that sends nothing. Fix before you announce.
  • Cosmetic: alignment, typos, a slow page that still works. Fix in the first week.

Then, for each item, write the fix next to the bug before you start coding. "Confirmation email in spam" becomes "set up SPF and DKIM for the sending domain". "Button under cookie bar on phone" becomes "add bottom padding equal to the banner height below 640px". Writing the fix first makes the work smaller and stops you from re-investigating the same bug twice.

When you do not have 20 minutes

The list above is what a QA person does on day one. If you are launching in an hour, do steps 1, 3 and 4 and skip the rest. If you are launching this week and have nobody to do it, AnyTest's testing agents can run these flows against your URL and leave you a report; the free capability audit on that page shows what they would test on your site before anything runs.

FAQ

How often should I repeat this checklist? Before every release that touches signup, login, payment or the layout. For a small app that is roughly weekly. If that sounds like too much, that is the point where an automated end-to-end suite pays for itself.

Do I need a staging site for this? No. Running the checklist on production with a test account and a test payment mode is fine, and it is the only way to catch problems with the real email provider and the real domain.

What is the difference between this and automated testing? This checklist is a one-time manual pass. Automated end-to-end tests do the same clicks on every release without a person. AnyTest has agents write those tests from your URL; the result per test is PASSED, FAILED with a step timeline, or NEEDS ATTENTION when a human should judge.

Which browsers should I test? The one most of your visitors use, which for most sites is Chrome on Android and Safari on iPhone. Check your analytics before you spend time on the rest.

What does a pre-launch QA audit cost? Doing it yourself costs the 20 minutes above. On WURK, AnyTest runs a one-time website QA audit for $5: an automated pass on your URL and a report with a proposed fix for every issue, within 2 days. Order it here: https://wurk.fun/store/05e528d0-1151-449e-8527-2e414ef2cdd7

Conversation

Join the conversation

Share your thoughts with the author and other readers.

Comments0

Checking your account…

Latest comments

0
No comments yet. Be the first to share your thoughts.