Manual and automated website testing: where each one fits

The question is not which approach is better. They answer different questions. A person can tell that a checkout is confusing; a script cannot. A script can check two hundred links in a minute after every deployment; a person will get bored and miss one. The useful question is which checks on your site belong to which approach.

What manual testing is good at

Manual testing means a person using the site deliberately, following test cases and also looking around them. Its strengths come from judgement:

• Usability. Whether a flow makes sense, whether instructions are clear, whether a visitor would know what to do next.
• Visual problems. Overlaps, awkward wrapping, images that look wrong, inconsistent spacing.
• The unexpected. A person notices the thing nobody wrote a test for: a strange delay, a confusing message, a broken link in a place nobody listed.
• Accessibility judgement. Whether alternative text actually describes an image, whether focus order makes sense, whether an error message helps. The W3C's guidance on evaluation tools states plainly that "Tools cannot check all accessibility aspects automatically. Human judgement is required."
• New features. The first time something is tested, a person exploring it learns what should later be automated.

Manual testing is slower and varies between testers, which is why written test cases matter: they make manual runs comparable.

What automated testing is good at

Automated testing means scripts and tools that check the site without a person driving each step. Its strengths come from repetition:

• Regression. Running the same checks after every update to confirm that what worked still works.
• Volume. Checking every page for broken links, missing titles, or images without alternative text.
• Consistency. The same check, done the same way, every time.
• Speed at scale. Running a flow in several browsers at once.
• Monitoring. Checking a live site on a schedule, such as submitting a test form every day and alerting someone if it fails.

Automation costs effort to set up and to maintain. Scripts break when a page changes, even when the change is fine, and someone has to fix them. A neglected automated suite that nobody trusts is worse than none.

Kinds of automated checks a small site can use

Not all automation means writing test scripts. Several useful kinds need little or no code:

For a small website, the first three rows give a good return for little effort. Scripted end-to-end tests make sense when a flow is valuable and changes often, such as a booking system that is updated monthly.

Automated accessibility checks, in particular

Automated accessibility checkers are worth running, and worth understanding. They find issues that can be detected from the code, such as missing labels, empty buttons, or text with low contrast. They cannot tell whether alternative text is accurate, whether a heading structure makes sense, or whether a page can be used with a keyboard in a sensible order. The W3C's selecting-tools guidance warns that tools "can produce false or misleading results" as well. Treat a clean automated report as the start of an accessibility review, never the end.

How to split the work on a small site

A practical split for a small or medium website:

1. Launch Manual testing of every flow, template, browser and device in scope, using written test cases. Run automated link, accessibility and performance checks alongside, and review their results by hand.
2. Straight after launch Set up uptime monitoring and a scheduled link check. Both take minutes and catch the most visible failures.
3. After the first few updates Notice which manual checks you repeat every time. Those are candidates for automation.
4. When a flow earns it Write scripted tests for the one or two flows that would cost most if they broke, such as enquiry delivery or checkout.
5. Every release Run the automation, then do a short manual pass over whatever changed. Automation covers what you know; the manual pass looks for what you do not.

Exploratory testing

One form of manual testing deserves its own mention. Exploratory testing means a tester working without a fixed script, using what they learn as they go to decide what to try next. It is structured in its own way: a session has a goal, such as "find ways the booking form can produce a wrong booking", a time limit, and notes of what was tried and found.

Exploratory sessions find the defects that written test cases miss, because test cases only check what someone thought of in advance. They suit new features, complex flows and areas where defects have clustered before. A good test plan includes some exploratory time alongside the scripted cases, and records what each session covered so the effort is visible.

Signs you need more automation

• The same manual regression checks take longer every month.
• Defects that were fixed come back after updates.
• Releases are delayed because nobody has time to test.
• The site has flows that change often and matter a lot.

Signs you need more manual testing

• Automated checks pass, but visitors still report problems.
• Nobody has used the site end to end, as a visitor, for months.
• New features go live with only automated checks behind them.
• Accessibility work relies on scan results alone.

Costs that are easy to underestimate

Automation can save time, but only once its own costs are counted:

• Setup. Choosing a tool, writing the first tests, and running them reliably in the browsers you care about.
• Test data. Automated tests need accounts, products or bookings to work with, and a way to reset them so each run starts from the same state.
• Maintenance. Every change to a page's structure can break a test that was working. Someone has to tell a real failure from a test that needs updating.
• Noise. Tests that fail now and then for no clear reason, such as a timing problem, train people to ignore failures. That is worse than having no test.

Manual testing has its own hidden costs: it depends on the tester's attention, it is hard to repeat identically, and it takes the same time on the tenth run as on the first. The aim is to put each check where its costs are lowest for the value it gives.

What a small automated set can look like

For a small website that changes every month or so, a modest automated set might be:

• An uptime check on the home page and the contact page.
• A weekly link check of the whole site.
• An automated accessibility scan of the main templates after each release, with results reviewed by a person.
• One scripted test that submits the main enquiry form on the live site and confirms the message arrives, run daily.

That set takes little time to maintain and protects against the failures that cost most. Everything else stays manual until there is a clear reason to automate it.

A note on testing with real users

Neither manual testing by a QA tester nor automation replaces watching real people use a site. Usability testing with representative visitors, including disabled people, shows problems that testers who know the site cannot see. It is a different activity from QA, with its own methods, and it is worth doing when a site serves a broad public.

Sources

• Selecting Web Accessibility Evaluation Tools, W3C WAI

Sources were read on 4 November 2026.