# Automated website tests: what a business owner gets

Automated tests check the contact form, the checkout and the phone link before every change. What that means for your business and what to ask a developer.

**Canonical:** https://spoko.space/blog/automated-website-tests-for-business-owners/  
**Language:** en  
**Published:** 2026-09-24  
**Tags:** testing, web development, business website, WordPress  
**Category:** Guide

---
**Automated tests are why a change to your website next year will not break the contact form, the checkout or the phone link.** Before every release, a program goes through the site the way a customer would and checks that the things bringing in enquiries still work. If they don't, the change does not go live.

This post is for the person who pays for a website, not the one who builds it. There is no code here, and tools appear by name only. It answers what changes for a business when a developer says "the site has automated tests", and how to check whether that is true.

## What a test actually checks {#what-a-test-actually-checks}

An automated test is a short script, written once, that a computer repeats on every change. On a business website it usually looks like this:

1. Open the homepage and check that it loads.
2. Go to the contact page, fill in the form, send it and check that the confirmation appears.
3. Check that the phone number in the header can be tapped and dials the right number.
4. In a shop: add a product to the cart, go to checkout, check that the total is right.
5. Open the same pages at phone width and check that the menu opens.

None of this is complicated. The difference is that a person does it once, at handover, and a test does it every single time, without getting tired and without skipping steps "because I didn't touch that".

## Types of automated tests: from one function to the whole customer path {#types-of-automated-tests-from-one-function-to-the-whole-customer-path}

A scenario like "open the site, send the form, check the cart" is what is called an **E2E** test (end-to-end): a program opens a real browser and walks the customer's path. A good set combines several kinds:

- **Unit tests** check one small part in isolation, for example whether the price with VAT is calculated correctly or whether a phone number has the right format. They take fractions of a second, so there can be many of them.
- **Backend tests** check what the customer does not see: whether the order was saved in the database, whether the confirmation email went out, whether permissions let in only the people they should.
- **E2E tests** check the whole thing through the customer's eyes. They are the closest to real use, but also the slowest and the most temperamental, so they are worth having only for the key paths.
- **Technical tests** guard things that are easy to miss: dead links, titles for Google, accessibility for people using a keyboard or a screen reader.
- **Visual tests** take a screenshot of every page and compare it with the previous one. They catch a button that moved or a photo that disappeared, which no other test would notice.

![Visual test results for the polo.blue parts catalogue: 67 pages compared with the baseline, all unchanged; below it a product page in three language versions](https://spoko.space/_spoko/testy-wygladu-vrt-polo-blue.DrooTJq_.webp)

At Google, according to *Software Engineering at Google*, roughly 80% of tests are small unit tests, 15% medium-sized ones and only 5% end-to-end. A small website does not need those exact ratios, but the direction is the same.

Here is how it looks in practice on four of my projects:

- **[ZapiszPrzepis](https://spoko.space/blog/zapiszprzepis-ai-first-app/)**, an app for saving recipes, has more than 70 unit tests and a set of E2E tests. The unit tests sit where a silent mistake is most likely: recognising where a recipe comes from, and reading the ingredients.
- **A service management dashboard** (customers, vehicles, invoices) has backend tests and around 140 E2E tests. After I [rebuilt how they run](https://spoko.space/blog/playwright-laravel-parallel-e2e/), the whole suite takes about 5 minutes instead of more than 34. That matters, because tests you have to wait half an hour for start getting skipped.
- **spoko.space**, this site, has mostly technical tests: links, titles, data for Google, language versions and accessibility in both themes. More on those in the section on how I test my own site and client sites.
- **[filament-ops-notify](https://github.com/spokospace/filament-ops-notify)**, my open-source package for Laravel, has 271 unit tests that run on every change against six combinations of PHP and Laravel versions, in under a minute.

![Test results of the filament-ops-notify package on GitHub: nine green jobs, including six combinations of PHP 8.3-8.5 with Laravel 12 and 13, code style, static analysis and package health, all in 43 seconds](https://spoko.space/_spoko/testy-jednostkowe-macierz-github.DTxPp1KX.webp)

## Why a change next year breaks something nobody touched {#why-a-change-next-year-breaks-something-nobody-touched}

A website does not stand still after launch. A new section is added, the price list changes, a plugin updates, someone swaps the header photos. Each change is made in one place, but the site is one whole: the same styles, the same scripts, the same template.

That is why the typical fault site owners bring to me is not a crash during a big rebuild. It is a small change after which something somewhere else stopped working. On my [WordPress rescue page](https://spoko.space/wordpress-rescue/), "broke after an update" is a separate symptom on the list because it happens so often.

Skipping updates is not an option either. According to Patchstack, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025, 91% of them in plugins. The official WordPress documentation therefore says to always update, and to back up first so there is something to go back to when things go wrong. Since version 6.6, WordPress itself checks after a plugin auto-update whether the homepage returns a fatal error, and if it does, restores the previous version of the plugin. It is a good safety net, but it checks one thing only: whether the homepage opens at all. A form that stopped sending messages gets straight through it.

The worst thing about faults after an update is that they are silent. The site loads and looks fine, the form just has not sent a message for two weeks. The owner finds out only when a customer calls to ask why nobody replied, or never finds out, because the customer went to a competitor.

## Tests on every deploy {#tests-on-every-deploy}

Checking the site by hand before a release is a good habit, but it has two weak spots. Someone has to remember to do it, including for a typo fix at 5 p.m. on a Friday. And people check what they changed, while what breaks is usually something next to it.

Automated tests run by themselves before a change reaches the live site, and they check the same full set every time, however small the fix. If one fails, the release stops and customers keep seeing the previous, working version.

I did not come up with this myself. DORA, the research programme run by Google Cloud, states plainly that tests run on every change lead to few errors in the version customers use, and to less painful deployments.

The same goes for updates. A new version of a plugin or the platform can go through the tests on a copy of the site first. If it breaks the form, I find out, not the customer who tried to send an enquiry.

## The maths: a bug your customers find vs a test written once {#the-maths-a-bug-your-customers-find-vs-a-test-written-once}

I won't give a universal figure here, because every business counts differently. You can do the sum yourself, in two columns:

| | A bug that reached customers | A test that stopped it |
|---|---|---|
| When you see it | When someone notices, sometimes weeks later | Before the release, within minutes |
| Who pays | You: in enquiries that never arrived | The developer: time to write the test |
| How often | Again with every new fault | Once, then the test guards every change |
| What is left | A customer who decided you don't reply | Nothing, the customer never knew |

To fill in the left column for your business you need two numbers: how many enquiries a week come through the form, and what an average job is worth. Multiply that by the number of weeks the form could stay silent before anyone noticed (when did you last send an enquiry through your own site?). The result is usually higher than the cost of writing a few tests for the paths that matter most.

In a shop, add the customers who hit an error and simply leave. Baymard Institute, which has researched online shopping for years, reports that 13% of shoppers abandoned checkout because the site had errors or crashed.

The best documented case that automated tests pay for themselves comes from Google. In 2005 the team behind the server that answers Google Search queries had a problem: more than 80% of releases contained bugs users could see and had to be rolled back. A rule was introduced that every change must include tests, and the tests run continuously. Within a year, emergency releases dropped by half, even though there were more changes than ever. That is how the book *Software Engineering at Google* tells it. Your site is incomparably smaller, but the mechanism is the same.

There is one more thing the table does not show. A year from now, neither I nor anyone else will remember that a change in the footer once broke a button in the checkout. The test will.

## How I test my own site and client sites {#how-i-test-my-own-site-and-client-sites}

This site, spoko.space, does not go live until it passes a full set of checks. Before every release I check automatically that no link leads nowhere, that every page has a proper title and description for Google, that the Polish and English versions point to each other, and that the site is readable and usable from the keyboard, in both the light and the dark theme. If any of those checks fails, the change waits until I fix it. What exactly I measure on the accessibility side is described on the [WCAG accessibility](https://spoko.space/accessibility/) page.

![Playwright report after the accessibility sweep of spoko.space: 104 tests passed, 0 failed, 1.7 minutes; below it the list of pages with the time each check took](https://spoko.space/_spoko/testy-dostepnosci-raport-playwright.DMlZ1U7H.webp)

More than once those checks have stopped a change of my own that looked fine by eye.

On client sites and web apps I pick the scope of automated tests according to what earns money for that business: for a guesthouse it is the booking form and the phone, for a shop the cart and the order, for a service business the quote form. Those few paths are checked automatically on every change, long after handover too.

## Tests in the age of AI: easy to get many, harder to get good ones {#tests-in-the-age-of-ai-easy-to-get-many-harder-to-get-good-ones}

AI can write hundreds of tests in an hour today, so tests are rarely missing. More often there are far too many, and some of them check the wrong thing.

A green result does not always mean the site works. A test can pass because it checks that the form is displayed, not that the message reaches the inbox. It can also check something so general that it passes whatever breaks. A test like that is worse than none, because it gives you a peace of mind nobody earned.

That is why the tests themselves need reviewing, just like the site's code. With tests written with AI's help, I first check whether a test can fail at all: I break the thing it guards for a moment and see whether it notices. If it doesn't, the test gets fixed or thrown away.

The number of tests has a price too. A hundred tests checking the same thing in different ways make every release slower and add nothing. A few well-chosen ones guarding the form, the phone link and the checkout are worth more than several hundred random ones.

### Where and when to run the tests {#where-and-when-to-run-the-tests}

How the tests are set up matters as much as what they contain. The simplest option is to run everything in the cloud on every change, for example in GitHub Actions. With a larger suite, though, that either costs a fair amount or quickly hits the free limits. I know this from my own account: once the free minutes run out, the cloud tests do not start at all, and the changes still need checking somehow.

So I split tests into three levels:

1. **Fast ones, before every push.** They run by themselves on my computer (a so-called hook, for example through Husky) before a change even leaves it. They take a few minutes: building the site, checking links and titles, and testing the key functions.
2. **Slow ones, before a change is merged into the version that goes live.** A full accessibility check of every page in both themes takes me about half an hour, so I don't run it for every typo, only once before the change reaches the site.
3. **On the live site, after release.** A short check of a specific path where customers actually use it. A development copy can be slow or behave differently from production (a different server, a different cache), so some cases can only be checked reliably on the live site.

## Questions to ask a developer before you sign {#questions-to-ask-a-developer-before-you-sign}

You don't need to know programming to judge the answer. Ask every developer these, me included:

1. **What on my site is checked automatically?** A good answer names specific things: the form, the phone link, the checkout, the login. A weak one is "we test everything" or "I check it in a few browsers" (that matters too, but it is a manual, one-off check).
2. **What happens when a test fails?** You want to hear that the change does not go live. If a test only sends someone an email they can ignore, you have half the protection.
3. **Do the tests keep running after handover?** Tests run once before launch and never again will not protect you from a change next year.
4. **How are plugin and platform updates handled?** On a copy first, through the tests, then on the live site? Or straight onto the live one?
5. **Who reviews the tests themselves?** If AI writes them, someone should read them and make sure each test can actually fail. "All green" on its own proves nothing.
6. **What do I get if I ever change developers?** The tests should be part of the site you receive, not knowledge that leaves with the developer.

More questions worth asking before you choose are in [how to choose a web developer](https://spoko.space/blog/how-to-choose-a-web-developer/).

## What tests won't catch {#what-tests-wont-catch}

Tests make sure that what worked still works. That is a lot, but not everything.

- **A bad design decision.** If the "Call" button is hidden at the bottom of the page, a test will confirm it works. It won't tell you nobody finds it.
- **Weak copy.** A test won't judge whether the offer persuades, or catch a typo in a price unless someone told it to check that exact amount.
- **Things nobody described.** A test only checks the scenarios someone wrote down. That is why choosing what to test matters more than the number of tests. Edsger Dijkstra, one of the pioneers of computer science, put it in one sentence in 1969: testing shows the presence of bugs, never their absence.
- **Problems outside the site.** If the mailbox that receives enquiries is full, the form sends the message correctly and you still won't read it.

Even Google writes plainly that not everything can be checked automatically, and that judging the quality of search results often takes a human. So tests don't replace a person looking at the site through a customer's eyes. They take over the dullest part of the job: clicking through the same things after every change.

## Summary {#summary}

- An automated test is a script written once that checks the form, the phone link, the checkout and the other paths that bring in customers, on every change.
- The costliest faults are the silent ones: the site looks fine while the form has not sent anything for weeks.
- Automated tests only work if they run on every deploy and stop a change that breaks something, after handover too.
- What counts is not the number of tests but what they check. Tests written with AI need reviewing, and a green result does not always mean the site works.
- Before you sign, ask what is checked automatically, who reviews the tests and what happens when a test fails.
- Tests won't judge the design or the copy. That is still a person's job.

If your site has already "broken after an update" once, or you are planning a new one and want the next change not to break it, [see how I build websites](https://spoko.space/web-development/).

## Frequently Asked Questions {#faq}

### What are automated website tests? {#faq-what-are-automated-website-tests}

Short programs that go through the site the way a customer does: they open pages, fill in the form, tap the phone number. They run by themselves before every release and stop it if something no longer works.

### Does a small business website need automated tests? {#faq-does-a-small-business-website-need-automated-tests}

It does not need many. A few tests of what brings in customers are enough: the contact form, the phone link, the offer page and the checkout if there is a shop. Those are the parts that break quietly.

### Do automated tests replace a person checking the site? {#faq-do-automated-tests-replace-a-person-checking-the-site}

No. Tests make sure that what worked still works. They cannot judge whether a new design is clear or whether the copy persuades. A person still does that, just without clicking through the whole site after every fix.

### How do I know whether my developer writes tests? {#faq-how-do-i-know-whether-my-developer-writes-tests}

Ask directly what is checked automatically and what happens when a test fails. A good answer names specific things (the form, the checkout, the phone link) and says that a change with a failing test does not go live.

### Are more tests better? {#faq-are-more-tests-better}

No. AI can write hundreds of tests in an hour, but some of them check things that do not matter or pass no matter what. A few well-chosen, reviewed tests of the form, the phone link and the checkout give you more than hundreds of random ones.

### Do tests protect against problems after a WordPress update? {#faq-do-tests-protect-against-problems-after-a-wordpress-update}

Yes, if updates go through the tests before they reach the live site. A plugin that breaks the form is then stopped on a copy of the site, and customers never notice.


## Sources {#sources}

- [Software Engineering at Google, ch. 11: Testing Overview](https://abseil.io/resources/swe-book/html/ch11.html) — The Google Web Server story: after tests became mandatory, emergency pushes dropped by half
- [DORA — Test automation](https://dora.dev/capabilities/test-automation/) — Google Cloud DORA research on what automated testing on every change delivers
- [WordPress.org — Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/) — The official guide: always update, but back up first
- [Make WordPress Core — Merge Proposal: Rollback Auto-Update](https://make.wordpress.org/core/2024/04/19/merge-proposal-rollback-auto-update/) — A plugin auto-update can take a site down; the built-in guard only checks the homepage
- [Patchstack — State of WordPress Security in 2026](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/) — 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins
- [Baymard Institute — Cart Abandonment Rate](https://baymard.com/lists/cart-abandonment-rate) — 13% of shoppers abandoned checkout because the site had errors or crashed
- [Software Engineering Techniques, NATO conference report (1969)](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF) — The source of Dijkstra's line that testing shows the presence of bugs, not their absence