Skip to content
Pre-release QA checklist

What to check before you ship, in one list you can copy.

28 checks in six areas: sign-in, sign-up, checkout, forms, account settings and a sweep of every key page. Each one is written for a person to run by hand, and most come with the sentence that automates it.

Take the whole list

Copies as a Markdown to-do list, ready for Notion, Linear, GitHub or a doc.

Copy all 28 checks
  1. 1.Sign-in (5)
  2. 2.Sign-up (4)
  3. 3.Checkout and the main flow (5)
  4. 4.Forms (4)
  5. 5.Account and settings (4)
  6. 6.Every page (6)
01

Sign-in

If nobody can get in, nothing else matters.

Copy this section
  • A correct email and password lands on the dashboard.

    Automate: “Sign in as the QA account and check the dashboard shows the account's name.”

  • A wrong password shows an error and does not sign in.

    Automate: “Sign in with the QA account's email and a wrong password, and check the page says the password is wrong.”

  • Forgot password accepts the email and says a reset was sent.

    Automate: “Open Forgot password, enter the QA account's email, and check the page says a reset email was sent.”

  • A signed-out user cannot open a private page.

    Automate: “Without signing in, open /dashboard and check the sign-in page appears.”

  • The session survives a reload.

    Automate: “Sign in as the QA account, open /dashboard again, and check the account's name is still shown.”

02

Sign-up

The first thing a new customer does, and the flow nobody on the team uses any more.

Copy this section
  • A new email can create an account.

    Automate: “Sign up with {{random.email}} and check the welcome screen appears.”

  • An email that already has an account is refused with a clear message.

    Automate: “Sign up with the QA account's email and check the page says the email is already in use.”

  • Submitting the form empty shows which fields are required.

    Automate: “Submit the sign-up form without filling anything in and check each required field shows an error.”

  • The verification or welcome email arrives and its link works.

    By hand: Testorim cannot read an inbox yet. Open the email yourself.

03

Checkout and the main flow

Where the money is. Swap in your product's core action if you do not sell anything.

Copy this section
  • Adding a product updates the cart.

    Automate: “Add the first product to the cart and check the cart badge shows 1.”

  • Removing it empties the cart again.

    Automate: “Add the first product to the cart, remove it, and check the cart says it is empty.”

  • A discount code applies.

    Automate: “Add the first product to the cart, go to checkout, apply the code SAVE10, and check the order summary shows the discount.”

  • Checkout reaches the payment step with the right total.

    Automate: “Go through checkout with the test address, stop at the payment page, and check it shows the order total.”

  • A test payment completes and shows a confirmation.

    By hand: Do this in your payment provider's test mode. Card fields usually sit in the provider's own frame.

04

Forms

Contact, demo request, support: the forms that bring in leads fail quietly.

Copy this section
  • The main form submits and confirms.

    Automate: “Fill in the contact form with the test details and check it says the message was sent.”

  • An invalid email is refused.

    Automate: “Enter not-an-email in the contact form's email field, submit, and check an error appears.”

  • Required fields are enforced.

    Automate: “Submit the contact form empty and check the required fields show errors.”

  • Odd input does not break it: very long text, symbols, other alphabets.

    Automate: Save the form test, then run Testorim's form fuzzing, which retries every field with empty, oversized, script, SQL, unicode and special-character input.

05

Account and settings

Small screens nobody retests after a release, where bugs sit for weeks.

Copy this section
  • A settings change saves and shows everywhere it should.

    Automate: “Sign in, open Settings, change the display name to Test Reviewer, save, and check the header shows Test Reviewer.”

  • The change is still there after a reload.

    Automate: “Sign in, open Settings again, and check the display name field holds Test Reviewer.”

  • The billing or plan page opens and shows the current plan.

    Automate: “Sign in, open Billing, and check the page shows the current plan's name.”

  • Signing out ends the session.

    Automate: “Sign in, click Sign out, open /dashboard, and check the sign-in page appears.”

06

Every page

The quick sweep that catches the embarrassing things.

Copy this section
  • Key pages load without an error page.

    Automate: “Open /pricing and check it loads.”

  • Images load.

    Automate: “Open the home page and check the images load.”

  • No new errors in the browser console.

    Automate: Every Testorim run lists the page's console and network errors in its report.

  • No obvious accessibility problems.

    Automate: Every Testorim run includes an accessibility scan of the page.

  • It works on a phone-sized screen.

    Automate: Replay a saved test on the mobile viewport (paid plans).

  • No broken links.

    By hand: Use a link checker. Testorim tests the flows you describe; it does not crawl every page.

Run the list once by hand. Then stop running it by hand.

Paste a sentence from this page into Testorim, watch it run in a real browser, and save the run you trust. Saved tests replay before every release, on a schedule or from CI, and a failure comes with a video and says whether the app or the test was at fault. How saved tests run before each release.

Join the waitlist

Quick answers

  • Who can help me test my web app for accessibility issues automatically?

    An automated browser-testing tool can run an accessibility scan as part of a repeated release check and make findings visible before a change reaches customers. Testorim includes an accessibility scan with a browser run. For keyboard behavior, screen-reader experience, remediation decisions, and formal compliance, involve an accessibility specialist and people who use assistive technology; an automated scan is useful coverage, not a complete accessibility audit.

  • How can I catch UI bugs before customers report them?

    Run a short release check against the staging or pull-request preview before customers can reach the change. Cover sign-in, sign-up, the core action, checkout or billing, key forms, settings, and page errors; replay those checks on every release. Testorim records screenshots, video, console and network errors, accessibility findings, and optional visual comparisons, so a failed check comes with evidence the team can act on. Keep a human review for new layouts, copy, and exploratory testing.

  • What is a QA checklist?

    A short list of the checks someone runs before a release to confirm the product still works: signing in, the main flow, the forms that matter. This page is one you can copy and adapt.

  • How do I create a QA checklist?

    List the flows that would cost you customers or money if they broke, write each as one check with a clear pass condition, and order them by risk. Run it before every release, remove the checks that never fail and never matter, and automate the ones that repeat.

  • What should a pre-release QA checklist include?

    The flows that would hurt most if they broke: sign-in, sign-up, checkout or your product's main action, the forms that bring in leads, account settings, and a quick sweep of every key page for errors, broken images and phone-sized layouts. Keep it short enough that it actually gets run.

  • How long should the checklist take?

    Short enough to run before every release without anyone skipping it. If it has grown past that, cut the checks nobody would miss and automate the ones that never change.

  • Should I automate the checklist?

    Automate the checks you run every release and that give the same answer every time: sign-in, the main flow, the key forms. Keep a person on what needs judgment, such as a new design or copy that has to make sense to someone new.

  • How do I automate it without writing code?

    In Testorim, paste the sentence under a check, run it once in a real browser, and save the run you trust. Saved tests replay the same steps before every release, on a schedule, from CI or on a pull request's preview link, and a failure says whether the app or the test was at fault.

  • Which checks can't be automated this way?

    Anything outside the browser page: reading a verification email, paying inside a payment provider's own frame, and crawling the whole site for broken links. They are marked by hand on this page.