How to Test Software Before You Launch It

Test like a customer, not like a builder

Builders test the paths they built, in the order they built them, with sensible data — and that is precisely why launch-day surprises exist. Customers arrive from an ad, tap around out of curiosity, type their phone number into the name field, lose connection halfway through checkout, and press the back button at the exact moment nobody planned for. Acceptance testing means impersonating that person for a day.

Two rules make the difference. First, use a fresh account on a device you do not develop or administer from — logged-in admin sessions hide entire categories of bugs. Second, follow written steps and record outcomes as you go; ad-hoc clicking around feels like testing but leaves no evidence of what was covered and no way to re-verify after fixes. The checklist below is your script — print it, and mark every line pass or fail.

What launch bugs cost, in published numbers

The macro number is startling: CISQ, the Consortium for Information and Software Quality, estimated the cost of poor software quality in the US at $2.41 trillion for 2022. You are not operating at national scale, but the mechanics that build that figure — defects found late, rework, lost transactions, abandoned customers — are identical in a five-person business, and they compound daily until someone finds the bug.

Scale it to a small store and the arithmetic is uncomfortable enough. A shop doing 20 orders a day at a $50 average sees $1,000 a day through checkout; a payment bug that silently fails one attempt in five leaks $200 a day, which is $1,400 a week — likely more than the testing day costs in anyone's time, and unlike the testing day, it recurs. Speed bugs leak similarly: Google's research, published as The Need for Mobile Speed, found 53% of mobile visits abandoned when a page takes longer than three seconds to load. None of these failures announces itself. That is the case for hunting them on a schedule.

The money paths, twice

Payment bugs cost the most and are tested the least, because testing them feels risky and slightly tedious. Do it first, while you are fresh. Every payment provider offers a test mode with cards that simulate success, decline and expiry — Stripe's are the best documented — so there is no excuse for the first failed card your system meets being a real customer's. Run each path twice: once to find bugs, once to confirm the fix did not break its neighbours.

• Complete a purchase end to end with a test card, and confirm the money shows in the provider dashboard.
• Pay with a declining test card — the customer should see a clear message, not a spinner or a blank page.
• Abandon a checkout halfway, then return — no double charge, no phantom order in the admin panel.
• Issue a refund from the admin side and confirm the customer is notified and the records reconcile.
• For subscriptions: cancel one, and verify access ends when it should — not immediately if they paid for the month, not never.
• Check the amounts, currency and tax lines on the receipt against what the page displayed before payment.

Bad data and broken journeys

Every form is a promise that someone will fill it in wrongly. The system's job is not to prevent that — it cannot — but to fail politely: a specific message, no lost work, no half-created records. This is the section where AI-generated and hand-written code alike hide their gaps, and it takes twenty minutes to probe thoroughly.

• Submit every form empty. Each required field should say so, by name, without wiping what was typed elsewhere.
• Enter wrong formats — letters in phone fields, an email without an @, a date of birth in the future.
• Paste absurd length: a 5,000-character message, a 200-character name. It should truncate or refuse, not crash the page.
• Try to book the unbookable: yesterday's date, two appointments in one slot, a quantity of zero or minus one.
• Double-click every submit button once — exactly one order, one email, one charge should result.
• Kill your connection mid-submission, restore it, and check nothing half-saved and the retry path makes sense.

Access, privacy and the emails nobody sees fail

Permissions bugs are quiet: nothing crashes, everyone carries on, and one day a customer notices they can read someone else's invoices by changing a number in the address bar. Test access by attempting what should be forbidden, from a second account — never by reading the settings screen and believing it. Email deserves the same scepticism, because delivery fails silently and every failed message is a customer who thinks you ignored them.

• Log in as an ordinary customer and try to open admin pages by pasting their addresses directly.
• From customer account A, try to view account B's orders, bookings or documents by editing IDs in the URL.
• Log out, press back — private pages should not remain readable from the browser history.
• Trigger every automated email — welcome, confirmation, reset, receipt — and receive each in a real inbox, checking spam.
• Send a password reset and confirm the link works once, then expires or rejects reuse.
• Confirm the site runs on https everywhere, including the payment and login pages a customer would check.

Devices, speed and the unglamorous checks

A meaningful share of your traffic will arrive on phones, over mobile networks, in browsers you did not choose — so at least one full test pass must happen there. Borrow a device from a different ecosystem than your own if you can. Speed belongs in the same pass: a page that feels instant on office wi-fi can take long enough on a train that customers assume it is broken and leave.

The numbers say this is the main event, not an edge case. Statcounter's figures put mobile devices at roughly 60% of global web traffic in 2025, and Google's mobile-speed research found 53% of mobile visits abandoned beyond a three-second load. A product tested only on a developer's desktop has therefore been verified for the minority of its audience, under the most forgiving conditions it will ever meet.

• Complete the core journey — including payment — entirely on a phone, on mobile data, not wi-fi.
• Rotate the phone, use the on-screen keyboard everywhere, and check nothing important hides behind it.
• Try the second browser: Safari if you tested in Chrome, or the reverse. Layout and payment quirks differ.
• Load the heaviest pages with the browser's network throttling set to a slow connection and judge honestly.
• Check images are not silently enormous — multi-megabyte photos are the most common cause of slow small-business sites.
• Print or save-to-PDF anything customers will keep: receipts, confirmations, tickets. Broken print layouts erode trust.

Testing AI-written code: the same checklist, applied harder

Much of what you are accepting was probably machine-drafted, whoever built it: Stack Overflow's 2025 Developer Survey found 84% of developers using or planning to use AI tools, while 46% said they do not trust the accuracy of AI output — up from 31% only a year earlier. Google's DORA research in 2024 measured the same tension, with 75.9% of respondents relying on AI for part of their work and 39% reporting little or no trust in AI-generated code. The practitioners closest to the tooling are telling you, in survey after survey, that review and testing carry the weight.

This is exactly how disciplined AI-assisted delivery already works. At PINCLER, AI writes boilerplate, tests and first-draft interfaces; senior engineers review architecture, security and every release — the split we apply across all 79 documented projects listed at /research/what-you-can-build. From your side of the table nothing about this checklist changes, and that is the point: acceptance testing verifies behaviour, not authorship. Trust is not a test plan, whoever — or whatever — wrote the code.

The one-day test plan, hour by hour

Here is the whole checklist sequenced into a working day. The ordering is deliberate — money first while you are fresh, devices late because earlier fixes need re-checking there anyway — and the final half hour of writing up is what turns a day of clicking into evidence a developer can act on.

Launch day: monitoring and the way back

The final checks happen before the announcement, not after the first complaint. Know how you will hear about problems — error alerts to a Slack channel or inbox, uptime monitoring on the key pages — and know the rollback plan: who can revert to the previous version, how long it takes, and what happens to data created in between. Teams that can answer those questions treat launch bugs as small events; teams that cannot, hold emergency calls. Ask your developer for both answers in writing as part of handover — at PINCLER this is standard, and the 14–60 day warranty means anything the checklist catches after launch is fixed at our cost, not yours.

A note on proportion: this checklist is a day of work, and it is enough for most small-business launches. It does not replace the developer's own automated tests, and products handling medical, financial or other sensitive data at scale justify professional security testing beyond anything here. For everything else, a printed checklist and a sceptical afternoon deliver most of the value at none of the cost. If you are still choosing who will build the thing you will one day test, our use-case pages show what tested-and-warrantied delivery looks like at a fixed price — and a free 30-minute call is a good place to ask any team how their work gets verified.