Skip to content
, Home

Quality & Engineering Leadership

Test architecture
for faster feedback and dependable releases.

I help engineering organisations design testing around their product risks, system boundaries and delivery model. I find where coverage is missing, where tests duplicate effort and where unreliable feedback slows teams down, then define the target architecture and a roadmap for implementing it.

Discuss your test architectureSee the full offer

The real question

What does a green build actually give you confidence to release?

Answered in the exampleTest architecture for one journey

Delivered work

From my employment: work delivered in roles I held, not consulting engagements. Selected roles

  • 4–5 days → 1–2 hours

    Regression before releases of a global news publisher’s flagship app, with automation across the testing layers and on physical devices. The end point is automated test execution time.

    Read the case study

  • 100% of endpoints

    Automated API coverage at a UK property-technology company, from a Playwright framework introduced alongside desktop testing. It describes endpoint coverage, not every input, permission combination or failure scenario.

    Read the case study

  • Three in four

    Eval pass rate within a month at an AI-native language-technology platform, up from just over half, after unstable tests and assertions were improved. The failures left were known product issues.

    Read the case study

01Questions

The questions
it answers.

How verification is designed, built and maintained: which risk is checked where, and what a pass proves. Quality strategy sets the priorities; CI/CD runs the checks in delivery.

  • What does a passing test prove?

    Each check is reviewed for its scenario, its assertions and how it fails. A tag records intent, not the ability to detect a violation.

  • Which checks run when?

    On a change, before a release or on a schedule. Selection follows change impact, dependencies and risk, and widens when the impact is uncertain.

  • Where is coverage missing, and where is it duplicated?

    Checks trace to requirements and risks, so you can see what nothing would detect and what is verified twice at a costlier level.

  • What gets automated first?

    Ordered by failure impact, defect likelihood, how late a failure would surface, cost and signal reliability. A payment or permissions flow that rarely changes can still come first.

02Decisions

Six decisions
shape the architecture.

Each is a trade-off. These are the ones I make with your engineers, and how.

  • Which risk is tested at which boundary?

    Each risk sits at the lowest level that can detect it: rule variations in unit tests, interfaces in contract and integration tests, only the assembled journey end to end.

    In practice: checks at each layer, and integration tests where the apps met their platform

  • Real service, substitute or isolated environment?

    A real dependency buys confidence at the cost of speed and stability; a substitute, the reverse. I choose per dependency, and back a substitute with a contract test.

  • How do tests stay repeatable and safe to run in parallel?

    Each test creates its own data and cleans up, or runs against an isolated copy. I look first for shared accounts and suites that depend on running in order.

  • What makes a pass evidence?

    A test asserts the outcome: the state that changed, the record written, the message sent. I look for tests that pass without checking what happened.

    In practice: AI evals that test the feature

  • What runs on a change, before a release and on a schedule?

    Fast checks on every change; slower, wider ones before a release or on a schedule. An unchanged feature can still break when shared code, configuration or an integration changes.

  • Who owns a failing test, and how fast is it explained?

    Every suite has an owning team, and a failure says where to look. Unreliable tests are quarantined with an owner and a date; checks tied to no live risk are retired.

03Example

One journey,
worked through.

An illustrative architecture for an invented document-processing product. Yours would start from your system and your risks.

  1. UploadThe customer sends a document through the web app.
  2. ValidationRules decide whether it is accepted.
  3. ProcessingA service converts it, calling storage and a third-party engine.
  4. Agent summaryAn AI agent reports what was done.
  5. DownloadThe customer collects the result.
Test architecture for one journeyIllustrative example: an invented product, not real data

  • A validation rule accepts or rejects the wrong document

    Where it is verified
    Unit and component tests.
    Why there, and what a pass shows
    Fast and precise across every rule variation. A pass shows each one accepted or rejected for the right reason.
    When it runs
    On every change.

  • Two services disagree about an interface

    Where it is verified
    Contract tests, plus integration against the real service.
    Why there, and what a pass shows
    A contract holds each side to what the other expects. A pass shows the consumer’s expectations met by the provider’s actual responses.
    When it runs
    Contracts on every change to either service; integration before merge.

  • The journey from upload to download breaks

    Where it is verified
    A few selected end-to-end tests.
    Why there, and what a pass shows
    Only the assembled system shows what the customer gets. A pass shows the download is the processed version of the upload, not just a success response.
    When it runs
    Before a release, and on a schedule.

  • A dependency is slow or fails part-way

    Where it is verified
    Failure and recovery tests, with the dependency substituted.
    Why there, and what a pass shows
    A substitute can time out or fail on demand; a real service cannot. A pass shows the job ends in a known state, with nothing duplicated or half-written.
    When it runs
    On changes to the integration, and on a schedule.

  • The agent says the work is done when it is not

    Where it is verified
    State assertions, plus a behavioural evaluation of the reply.
    Why there, and what a pass shows
    What the agent says is not evidence. A pass shows the stored result matches what the reply claims; the evaluation judges the reply over repeated runs.
    When it runs
    On changes to the prompt, the model or the tools, and before a release.

What a green build means here: each of these risks was checked where a failure would show, and the gaps are named.

  • What it assumes

    Interfaces that can be put under contract, dependencies that can be substituted in a test, and a deployed environment close enough to production to trust.

  • What it leaves open

    Performance under load, the security of uploaded content, accessibility and cross-browser behaviour. How many end-to-end tests are enough depends on where your incidents have come from.

04Scale

One architecture across teams,
repositories and stacks.

What changes when the architecture has to hold across teams, repositories and technology stacks.

  • Shared conventions

    One definition of each test level, one vocabulary for product areas and risks, and results in one shape, whatever the framework underneath.

  • Team ownership

    Every suite, shared fixture and environment has an owning team. A journey that crosses teams has a named owner too.

  • Adoption in steps

    Reference patterns a team can copy into its own repository. New tests follow the conventions first; existing suites migrate where it pays.

From my employment

05Approach

How I work
on it.

  1. Diagnose the current system

    I look at the architecture, the critical journeys, recent incidents, the suites you have, how they run and what they cost to maintain.

  2. Design the target architecture

    With your engineers I define the test boundaries, how dependencies, data and environments are handled, what the tests assert and who owns what.

  3. Prove it on one workflow

    I build or guide a pilot on a representative workflow, then judge it on feedback speed, reliability and how well a failure explains itself.

  4. Roll out in steps

    I order the migration and set up patterns your teams can reuse. Existing suites and frameworks stay unless the diagnosis shows they are the problem.

What you leave with

  • A current-state assessment: coverage gaps, duplicated checks, unreliable tests and costly dependencies.
  • A target architecture: test levels, system boundaries, and the strategy for environments and test data.
  • Decision records: why each approach was chosen and what it trades off.
  • A reference implementation: one representative workflow built to the agreed patterns, where included.
  • A migration roadmap: the changes in sequence, with their owners, dependencies and effort.
  • A measurement plan: feedback time, unreliable failures, investigation effort and defects that escape the targeted areas.

06Evidence

Delivered work,
from my employment.

Case studies of changes that were delivered and in use, not proposals. Each says what my part was and where its evidence stops.

Case studies

Where it sits in the assessment.

The Quality Maturity Assessment scores nine dimensions. These are the ones this work moves.

Open the assessment

The other topics.

  • Quality strategyWhat quality means for your product, who owns it, and how “good enough to ship” gets decided.
  • Organisational maturityWhere the organisation stands across nine dimensions, and which one is setting the ceiling.
  • Release confidenceA release decision that can point to what was verified and what was not.
  • CI/CDPipelines and feedback loops that tell the team quickly whether a change is safe to ship.
  • Fractional leadershipSustained direction across quality and delivery, without a full-time hire.

Where is the feedback slow,
unreliable or missing?

Describe the system, how it is tested today and what gets in the way. A first conversation establishes whether to start with a diagnosis or a pilot on one workflow.

Discuss your test architecture