"It's tested" is easy to say: five questions that show what was checked

Every developer says the site is tested. It is the easiest sentence in the trade to say and one of the hardest to check. Tested by whom, on what, and what happens when the thing you care about breaks?

I am a software engineer, and my full-time job at HP is in quality engineering, which means my day job is working out how software fails. This article is what I would want a business owner to know before they accept "it's tested" from me or anyone else.

• Testing finds problems. It cannot prove there are none. Be wary of anyone who says a site is bug-free.
• Nobody tests everything. A good developer tests the parts that would hurt most if they broke: payments, forms, bookings, sign-in.
• Ask what was tested, not whether. "I clicked around" and "an automated check runs the booking flow on every change" are very different answers.
• Testing before launch is not monitoring after launch. They answer different questions, and neither covers everything.
• A speed score from one test is one sample. Real visitors see a spread of results.

The international software testing body ISTQB lists seven basic principles. The first is that testing shows the presence of defects, not their absence. A test that passes tells you that one specific thing worked once. It does not tell you the site is free of faults.

That sounds like hair-splitting until you hear "it's been tested, so it's fine." It is not fine. It is "nothing we thought to check has failed yet." That is still valuable, and it is the honest claim.

The second principle is that exhaustive testing is impossible. Even a simple contact form can receive an effectively endless range of names, emails, messages, devices and connections. ISTQB's answer is to let risk decide the priorities.

So the useful question is not "did you test it all?" It is "what did you decide mattered most, and why?" For a local business site, my own list of what would cost you most if it quietly stopped working is short:

• The contact form or lead capture. A broken form looks fine and loses you customers.
• Anything that takes money or a booking.
• Sign-in to anything with customer data.
• The phone number, address and hours, because they are what people came for.

If a developer cannot tell you which parts they treated as most important, they probably did not decide.

The Next.js documentation, which describes the framework this site is built with, separates testing into a few kinds. Three matter to you.

• Unit tests check one small piece in isolation. For example: does the function that adds up an order total give the right number?
• Integration tests check that several pieces work together.
• End-to-end tests act like a visitor in a real browser: open the page, fill in the form, press the button, see the confirmation. The Next.js documentation describes them as testing user flows in an environment that simulates real user scenarios.

For a small business site, the end-to-end check is the one that matches your worry. You do not care whether a function is correct. You care whether a customer can book. The same Next.js page recommends end-to-end testing over unit testing for some newer kinds of components, because the tools for unit testing them are not fully there yet.

Playwright is a widely used tool for end-to-end tests, and its documentation has a short best-practices page. Three of its points translate directly into questions you can ask.

• Does the test look at what a visitor sees? The guide says the end user sees what is rendered on the page, so tests should check that, not internal details. A test that passes while the button is invisible is worthless.
• Is each test independent? The guide says each test should be completely isolated from the others and run independently. Otherwise one failure hides the next.
• Does it test things the developer controls? The guide says to test only what you control, and not to test third-party servers. The practical consequence: an automated check cannot prove that your card processor or email provider works. It can check that your site sends the right request.

The same page says that ideally tests run on each commit and pull request, meaning every time the code changes. A check that ran once before launch tells you little about next month's edit.

Testing happens before something goes live. Monitoring watches it afterwards. They are different jobs.

On my own client sites, every site is checked every five minutes, including the database and not only the page, and I am alerted if the check fails. That is worth having, and it also has a limit I state publicly: the check reads a status code. A checkout that breaks politely, showing an error message while the page itself loads fine, can still return a normal response and slip past it.

I would rather you know that than assume a green light means everything works. This is why a developer who says "it's monitored" is not answering the same question as one who says "the booking flow is tested."

I keep a script that scans this site's code and documents for contradictions, such as a price in one place that disagrees with the price in another, and I run it before pushing anything that touches copy or price. That is a small, boring example of testing what I care about: wrong numbers on a pricing page are a real way to lose trust, so a machine checks them instead of my memory.

It does not prove the site is perfect. It proves one specific class of mistake gets caught. That is what a good test does.

Speed is the other place "tested" misleads. Google's web.dev explains that lab data, such as a Lighthouse run, is one device on one network from one location, which makes it repeatable. Field data comes from the real people who visit and is a distribution of results, not a single number.

web.dev gives an example of one page where the lab test reported a main-content load of 3.0 seconds, while the 75th-percentile field figure for the same page was 1.8 seconds. Neither was wrong. They measure different things. Lab runs are good for finding what to fix, and real-visitor data is better for deciding what matters.

So if someone shows you a single speed score as proof the site is fast, ask whether it is a lab result or real visitor data.

Passing functional tests says nothing about security. The OWASP Top 10 is described by its authors as the reference standard for the most critical web application security risks, and it is a list of ways sites get attacked, not ways they get broken by accident. I am not a security auditor, and a general-purpose "tested" does not mean "penetration tested." If you hold sensitive data, ask directly what security checks were done and who did them.

1. Which parts did you treat as highest risk, and what did you check on them?
2. Is any of it automated, or is it all someone clicking around?
3. When I change something later, does anything re-run the checks?
4. What is watching the site after launch, and what would it not catch?
5. What have you not tested, and what is the plan if that breaks?

A developer who answers the last one without flinching is usually the one who tested properly.

If you want to talk through any of this for your own site, the hire page is the place to start.