Software testing checklist: how we test websites and apps before launch

A good software testing checklist covers ten areas before launch: core functions, devices and browsers, accessibility, performance, security, forms and email, payments, content, SEO and analytics, and backups. On a typical small business website that is two to four days of work spread across the project; on a mobile app it is closer to 20 to 30 % of the build. Below is the checklist we actually run at WE-DEV, with what each item catches, who does it and roughly what it costs. Copy it, adapt it, and hold any supplier to it, including us.

Why “we test everything” is not good enough

Every agency says it tests. Ask what that means and you often get “we click around on a few phones before go-live”. That catches the obvious breakages and misses the ones that hurt: the contact form that sends to a mailbox nobody reads, the checkout that fails only for Amex cards, the booking calendar that double-books when two people pay within the same minute.

A written checklist does two things. It stops tired people skipping steps at 6pm on launch day, and it gives you, the client, something concrete to sign off against. Most of the failures we have been asked to fix on other agencies’ sites were not hard bugs. They were checks nobody did.

How testing fits into a project

Testing is not a phase at the end. On our projects it runs in three layers.

1. Automated tests while we build

For custom PHP, Laravel and Node work we write automated tests for anything that handles money, permissions or data: price calculations, VAT, discount codes, user roles, API responses. Tools vary by stack (PHPUnit or Pest for PHP, Jest or Vitest for JavaScript, Playwright for browser flows). These run every time code changes, so a fix in one place cannot quietly break something elsewhere.

For a brochure WordPress site we do not write unit tests for every template. That would be cost without benefit. We do automate the boring checks: broken links, HTML validity, Lighthouse scores and accessibility scans with axe.

2. A staging site that matches live

Everything is tested on a staging copy that runs the same PHP version, the same caching and the same plugins as the live server. A surprising number of launch-day problems come from “it worked on my machine” differences: a host with an older PHP version, a firewall that blocks the payment webhook, a cache that serves the logged-in basket to the next visitor.

3. Manual QA, then your user acceptance testing

A person who did not build the feature works through the checklist below. Then you test it as a customer would. Developers are poor testers of their own work because they know which buttons not to press.

The pre-launch checklist

This is the list we use, slightly condensed. Items marked “apps” apply to Flutter iOS and Android builds.

Functional testing

• Every page loads without errors, and every link and button goes where it says.
• Menus, search and filters work with real content, including long product names and empty results.
• User accounts: register, log in, reset password, log out, delete account.
• Roles and permissions: an editor cannot see admin settings; a customer cannot see another customer’s orders by changing a number in the URL.
• Edge cases: zero, negative and very large quantities; apostrophes in names (O’Neill breaks more forms than you would think); postcodes with and without spaces.

Devices and browsers

We test on real phones as well as browser emulators, because emulators miss touch behaviour and on-screen keyboards covering form fields.

Accessibility (WCAG 2.2 AA)

• Automated scan with axe on every template, then manual checks, because automated tools catch only part of the problems.
• Keyboard only: can you reach and use every link, menu, form and modal with Tab, Enter and Escape? Is the focus outline visible?
• Screen reader pass with VoiceOver and NVDA on key journeys such as contact and checkout.
• Colour contrast at least 4.5:1 for body text, alt text on meaningful images, labels on every form field, error messages that say what went wrong.

Our full view on the legal side is in website accessibility and UK law.

Performance

• Lighthouse mobile score of 95+ on the key templates (home, service, product, article), tested on staging with production caching switched on.
• Core Web Vitals inside Google’s “good” thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. See Core Web Vitals explained.
• Images resized and served as WebP or AVIF, fonts preloaded, no plugin loading scripts on pages where they are not used.
• A basic load test for shops and booking systems before a known busy date, such as a Black Friday sale or ticket release.

Security

• HTTPS everywhere, with HTTP redirected and a valid certificate.
• Admin URLs protected, strong passwords, two-factor login for admin accounts.
• Forms protected against spam and injection; file uploads limited by type and size.
• Software, plugins and libraries up to date, with a check for known vulnerabilities.
• Error messages that do not reveal server paths or database details.
• Security headers set; Cloudflare in front where it makes sense.

For anything holding personal or financial data, a separate penetration test is worth considering.

Forms and email

This is the section most often skipped and most often broken.

• Every form submitted with real data, and the email actually received in the right inbox, not spam.
• Email sent through an authenticated service with SPF, DKIM and DMARC set on your domain. Gmail and Yahoo tightened sender rules in 2024 and unauthenticated mail from websites now goes missing far more often.
• Auto-replies read well and contain no placeholder text.
• Data from forms goes to the CRM or mailing list it should, with consent recorded.

Payments

• Full test purchases in Stripe or PayPal test mode with success, decline, 3D Secure challenge and refund.
• One real live transaction after launch, then refunded.
• VAT, delivery charges and discounts calculated correctly, including mixed baskets.
• Webhooks confirmed: an order paid on the payment provider shows as paid on the site, even if the customer closes the browser.
• Order confirmation emails and admin notifications received.

Content

• No test text, no “Sample Page”, no dummy products left in the database.
• Legal pages present: privacy policy, cookie policy, terms, company number and registered address in the footer (required for UK limited companies).
• Spelling, phone numbers and opening hours checked by someone who knows the business.

SEO and analytics

• Page titles and meta descriptions unique; one H1 per page.
• XML sitemap generated and robots.txt not blocking the site (the classic launch-day mistake is a staging “noindex” left switched on).
• 301 redirects from every old URL if this is a rebuild, tested from a list, not by memory.
• Analytics and conversion tracking firing only after consent where required. More in our guide to UK cookie banner rules.
• Search Console verified and sitemap submitted.

Backups, monitoring and recovery

• Automatic daily backups stored off the server, and one restore actually tested.
• Uptime monitoring that alerts a person, not just a dashboard.
• A rollback plan for launch day: if something breaks, how long to put the old site back?

Extra checks for mobile apps

• Builds tested on physical iOS and Android devices via TestFlight and Google Play testing tracks.
• Poor connection and offline behaviour: what happens on a train between Leeds and Manchester when the signal drops mid-payment?
• Push notifications, permissions prompts and deep links.
• App store requirements: privacy labels, data safety form, account deletion inside the app, screenshots. New personal Google Play developer accounts also have to run a closed test with a minimum number of testers before going to production, so build that time into the plan.

User acceptance testing: your part

UAT is where you test the site against what your business needs. We give you a short script for the journeys that matter (make an enquiry, buy a product, book an appointment, update a page in the CMS) and a simple way to report issues with a screenshot and the device you used.

Three tips from running a lot of these:

• Get someone who has never seen the site to try it. Your new receptionist will find things you cannot.
• Test on your own phone over 4G, not on office Wi-Fi.
• Report one issue per line. “The site looks a bit off on mobile” cannot be fixed; “on iPhone 13 the Book Now button is hidden behind the cookie banner” can be fixed in ten minutes.

How long testing takes and what it costs

Testing is time, so it has a cost. These are typical figures from our own projects, at our published hourly rates.

On our fixed-price website packages testing is included in the price, from the £350 Startup Website up to the £2,650 Business / E-commerce package. If you hire us by the hour, it comes out of your block. As a worked example, 20 hours of e-commerce testing and fixes before a big launch would be 20 × £65 = £1,300, less the 15 % 20-hour discount (£195), giving £1,105 + VAT, or £1,326 including VAT. Hours booked through Hire Us never expire, so unused testing time can roll into post-launch changes.

Is it worth it? Compare it with the cost of a broken checkout on a Saturday, or a contact form that silently failed for three months. We have seen both on sites handed to us for rescue, and in each case the fix took under an hour. Finding it took months.

After launch

Testing does not stop at go-live. In the first fortnight we watch error logs, form submissions and payment reports daily. After that, a maintenance routine takes over: updates tested on staging before they reach live, monthly checks of forms and backups, and a quick regression run after any significant change. Our guide to a WordPress maintenance plan covers what that should include.

If you are about to launch

If you are building in-house or with another supplier, use the checklist above as your sign-off list. If you want an independent pair of eyes, we can run a pre-launch QA audit on an existing site or app anywhere in the UK, remotely, and send back a prioritised list of issues. For new builds, testing is part of every web development and mobile app project we run.

Photo: Eden Constantino via Unsplash