Human-centric automation
for testing within
modern engineering.

Traditional 'test automation' has trained us to think about automated checks.

Write a test. Execute it. Get a result.

But testing is much bigger than test execution - and our use of automation should be too.

Automation can support exploratory testing, test data, environments, observability, evidence collection, analysis, debugging, reporting, testability, risk assessment, agents, orchestration and decision making.

It can help humans investigate, learn and make better decisions.

Automated checks are one use of automation in testing. They are not the whole of it.

Automating the actions a human performs does not mean we have replicated the testing that human was doing.

The clicking was rarely the valuable part.

The value came from what they noticed, what they questioned, what they compared, what they learned and the decisions they made because of it.

Good automation cannot compensate forever for a system that is difficult to test.

Improve the system itself.

Expose useful state. Provide useful interfaces. Make behaviour easier to observe and control. Make evidence easier to access. Reduce the friction required to begin testing.

And think beyond traditional automation.

Modern systems should be testable by humans, code and agents.

The easier a system is to interrogate, observe and control, the more options we have for testing it.

Too often we preserve the automation and lose the reason behind it.

Why does this test exist? What risk is it addressing? Why was it designed this way? What are we trying to learn or evaluate? What decision is it meant to support?

That intent matters.

Especially when something changes.

Without intent, maintenance becomes guesswork.

A human — or an AI — can inspect the implementation.

But that does not tell them whether they should fix the test, fix the product, change the evaluation, update the data or delete the test entirely.

Test design, risk and evaluation help define the intent.

Code, prompts, tools, workflows and agents are ways of implementing it.

Automation should be a response to a problem.

Not the starting point.

Understand the problem in its entirety.

Who has the problem? Why does it matter? What constraints exist? What would a useful outcome look like?

Then ask whether automation is needed at all.

Sometimes the answer is a new tool. Sometimes it is a small script. Sometimes it is an agent. Sometimes it is better testability. Sometimes it is a product or process change.

And sometimes the answer is to do nothing.

Choose the approach that best fits the context.

Do not choose the tool first and then bend the problem until it fits.

Build for progress, not perfection.

Coverage is not bad.

Blind coverage is.

Not every scenario is equally valuable. Not every behaviour deserves the same automation investment. And adding another automated test always has a cost.

It needs to run. It needs to be maintained. It needs to be investigated when it fails. And eventually, it may need to be changed or deleted.

Use risk to decide where automation provides meaningful value.

If a risk is already sufficiently mitigated at one layer, duplicating the same confidence elsewhere may add maintenance without adding much value.

Coverage can show progress.

Risk tells us whether that progress matters.

Evidence that meaningful risks have been mitigated is what creates confidence.

A result floating on its own tells us very little.

What ran? Why did it run? Against which version? What changed? What did the system actually do? What was observed? What evidence supports the outcome?

Traceability connects results to the wider story.

Risks. Requirements. Versions. Pull requests. Changes. Observations. Evidence. Decisions.

It allows us to reconstruct what happened later.

That matters for investigation. It matters for auditing. It matters for governance. And it matters when future humans or agents need to understand what we already know.

Do not simply preserve a pass or fail.

Preserve enough evidence to tell the story of what happened.

Testing has always involved orchestration.

Humans decide what to test. Gather information. Move data around. Interpret results. Connect observations. Write reports. Raise defects. Make decisions. And decide what should happen next.

Execution is only one event inside that wider system.

AI and agents now allow us to automate more of the surrounding work.

Bring together human testing, automated tests, tools, agents and engineering signals.

Capture results and observations somewhere useful.

Connect testing information to changes, risks and decisions.

Preserve what we learn.

Make that knowledge available to future humans and agents.

What you tested today should improve how you test tomorrow.

The opportunity is not simply to execute more tests.

It is to build a connected system that facilitates the whole of testing.