A brushed aluminium test body on a slim mount inside a wind tunnel, smoke lines streaming over it.

Service 09 · AI Test Automation

Know what your green build is worth

Tests get cut when they are a separate task. So we fold them into the change.

A change without passing tests does not exist
No separate test task left to defer
AI writes the mechanical suite with the work
People who know your domain do the exploratory testing

Example record

A release the gate stopped

So a model that got worse stays out of your release. The suite runs on each change, and a score below the baseline blocks it.

The failed cases arrive by name, with the diff.

pipeline · release gateSample log

Characterisation tests
behaviour recorded before the change
Pass
Tests against the spec
written from the acceptance criteria
Pass
A mock around the thing under test
flagged by review
Flagged
Evaluation suite against the baseline
score dropped on 6 named cases
Blocked
$

A workbench of precision measuring instruments, calipers and gauges laid out in a row.

What the suite measures

Tests run against the real thing

Your tests exercise the code they name, with no mock standing in for it.

Why your tests survive the deadline

A separate task with its own estimate can be deferred, and a date cannot. So the tests live inside the task.

The estimate includes the tests, so there is nothing separate to cut
The unit closes when its tests pass in your pipeline, not on a laptop
Exploratory testing is a session per release by a tester who knows your domain
A unit without passing tests shows in the record as a gap with an owner

Capabilities

What we look for in your suite

01Tests that assert the implementationAI-written tests tend to assert what the code does instead of what the requirement says. A test written from the code under test keeps passing and proves little.

02Mocks around the thing under testA suite that mocks its own subject is measuring the mock. It is the most common way high coverage catches nothing.

03Coverage that counts the easy paths twiceA number that rises while the risky branches stay untested. You get coverage measured against the specification.

04Suites that pass locally and fail deployedThe end-to-end layer runs against a deployed environment, because that is where your customers meet the failures.

05A model with no gateA model in your product needs a fixed dataset, a scoring method, a baseline and a gate that blocks release when the score drops. Without that harness, a prompt change ships on somebody’s impression.

06Legacy changed before it was characterisedBefore your untested system changes, we write tests that record what it does today, correct or not. They make a later change safe, and teams skip them first.

Tests that pass and check the wrong thing

What you hold after the first pass. AI writes the tests fast, and our test lead checks them against the requirement.

A dial indicator on a magnetic stand, its probe resting against a machined part on a granite surface plate.

A
Coverage measured against the specification, not the code
B
Every mocked subject, listed with its owner
C
The end-to-end suite running on the deployed environment
D
A scored gate on each model in the product

Model

What we fix, and what you decide

What we fix

F1Tests land with the unit, so there is no test task to cut
F2Verification is written against the specification
F3AI-written tests are reviewed for the anti-patterns they are prone to
F4A model in the product has an evaluation harness with a gate
F5Change old code, keep what works

What you decide

C1Coverage targets, and which environments the end-to-end suite runs against
C2Our pipeline, or work inside yours
C3The scoring method and threshold for a model gate

Where to go next

Next step

Send us the suite and the spec.

We measure one against the other, gap by gap. What you get is coverage you can defend at the release meeting.

Book a readiness review →