AI × QE / Modernize the work behind the AI

QE modernization
for AI enablement.

AI can help a team write and explain. To execute more work reliably, it needs a delivery system that can recreate an environment, control dependencies, check outcomes and preserve evidence.

Begin reviewed assistance where its prerequisites are met. Modernize the selected workflow alongside it, then widen execution when the evidence supports that scope. “Full AI enablement” here means supported assistance across the lifecycle with bounded execution and accountable review.

01 / A capability path

Modernization and AI adoption progress together

DORA's guidance connects reliable test feedback with testability, data, delivery practices and shared developer/tester responsibility. The progression below is our application of that guidance to AI-assisted QE. It is not an industry maturity certification. Q1, Q3

01Trusted work

Reviewed scenarios, expected outcomes and ownership

AI drafts with domain reviewA reviewer can identify a wrong answer

02Repeatable execution

Reliable suites, isolated data and controlled dependencies

AI drafts tests that run in CIAnother engineer reproduces the result

03Shared QE services

Reusable environments, contracts, artifacts and support

Assistance works across teamsA second team onboards and operates it

04Broader AI execution

Evaluated tools, bounded actions and recovery

Agents execute within approved scopeFailures stop, evidence persists, people can intervene

Proposed capability progression. Reviewed assistance can begin while foundations improve. Broader execution requires evidence for its specific scope. Modernization workstreams and sources

What must come first: trusted inputs and an accountable reviewer before relying on a draft; repeatable execution and independent outcome checks before relying on generated tests; supported operation and tested failure handling before expanding agent actions. Cloud migration and containerization are design choices within that work.

02 / Different capabilities, different jobs

Containers, virtual services and contracts

RUN

Containerization

Package and run real software with repeatable dependencies.

Example

A PostgreSQL instance created for one test run.

SIMULATE

Service virtualization

Replace selected dependency behavior with a controlled model.

Example

A WireMock provider with an intentional timeout.

CHECK

Contract testing

Check whether consumer and provider interactions agree.

Example

A provider change fails a reviewed Pact contract.

These capabilities complement each other. They do not establish complete business correctness or replace all real integration checks. Technology choices and limitations

A WireMock substitute can itself run in a container. That container packages the simulator; it does not turn the simulated provider into the real service. A PostgreSQL container, in contrast, runs a real database engine. A Pact check addresses an agreed interaction, while financial correctness still needs independent domain assertions. Q6, Q8, Q10

Option	Use when	What the team must still supply
Testcontainers	A test suite should own short-lived database or service instances.	A compatible runtime, permitted image access, readiness checks, isolated fixtures and cleanup. Q6, Q7
Docker Compose	A reviewed multi-service environment is useful for local development, testing or CI.	Pinned configuration, explicit health conditions, migrations, run isolation and teardown. Startup order alone does not establish readiness. Q4, Q5
Existing Kubernetes platform	Cluster-specific behavior or an already supported shared environment service justifies it.	Access rules, resource limits, network isolation, lifecycle ownership and support. A namespace alone is insufficient. Q11
Scripted VM or reserved system	Licensing, OS, hardware or legacy constraints make disposable containers unsuitable.	Versioned setup, a reliable reset procedure, booking and access ownership, and explicit limits on parallel runs.

Selection principle: choose the smallest supported environment that can answer the test's question. Retain production-relevant integration, performance, resilience and device checks where a smaller environment cannot establish them.

03 / The modernization backlog

Six workstreams connect platform changes to daily QE

Use the twelve-dependency assessment to identify gaps. These workstreams describe how to address them. Each proof is a proposed acceptance condition, to be agreed for the client.

1. Test strategy and testability

Starting pain. Manual regression packs, UI-heavy coverage and unclear expected outcomes.

Modernization work: Map critical journeys. Move suitable checks to unit, API and component suites; retain exploratory, usability and real integration coverage. Add observable outcomes and curate flaky tests.
Proof before expanding: A known defect is caught by an independent assertion, and another engineer reproduces the result.
AI contribution: Draft scenarios and test code from approved rules; reviewers own the expected outcomes.
Accountability: QE lead + application developers

2. Containerization and environment lifecycle

Starting pain. Few shared environments create booking queues and reset contention; setup depends on an individual.

Modernization work: Package suitable apps, test runners and dependencies. Pin versions, apply migrations, wait for readiness, seed isolated data and clean up even after failure. Use scripted VMs or reserved systems where containers do not fit.
Proof before expanding: Two runs do not interfere, a clean runner recreates the environment, and failed runs leave no unowned resources.
AI contribution: Propose setup changes through review; the pipeline owns execution and cleanup.
Accountability: Platform / DevOps owner

Q4, Q5, Q6, Q7

3. Service virtualization and contract fidelity

Starting pain. Without service virtualization, testing depends on limited vendor environments and their available failure, callback and edge-case behavior.

Modernization work: Create owned, versioned substitutes for supported protocols. Model state transitions, delays and failures; reset between runs. Compare contracts and behavior with the real integration on a defined schedule.
Proof before expanding: A deliberate contract mismatch fails a check, and timeout and duplicate scenarios can be replayed.
AI contribution: Draft mappings and suggest edge cases; integration engineers review the model.
Accountability: Integration lead + provider owner

Q8, Q9, Q10

4. Data, fixtures and domain checks

Starting pain. Teams reuse accounts and manually repair balances between tests.

Modernization work: Create permitted synthetic fixtures with valid business relationships, unique run identities and deterministic reset. Check money movement in the journal and balances, not just HTTP status.
Proof before expanding: The retry scenario rejects a duplicate transfer or a wrong journal entry even if the API reports success.
AI contribution: Suggest data combinations; independent checks validate relationships and outcomes.
Accountability: Domain QA + data / application engineer

Q2, Q10

5. CI execution and diagnostic evidence

Starting pain. Tests run late; failures produce screenshots without reproducible context.

Modernization work: Version the build, tests, fixtures and substitutes together. Retain assertions, logs, traces and artifacts by run ID. Keep mandatory suites and distinguish product, test and environment failures.
Proof before expanding: A failed required check stops promotion; evidence remains accessible after environment cleanup.
AI contribution: Draft evidence-linked triage and repair suggestions; retests establish whether a fix works.
Accountability: Developers + QE automation + DevOps

Q1, Q3

6. Shared platform service and team skills

Starting pain. A large manual QE team waits for environment access and coordinates reruns; adding staff does not increase vendor test capacity.

Modernization work: Provide maintained templates, onboarding, coaching, ownership, support hours and capacity. Introduce self-service environments only when the platform can operate them.
Proof before expanding: A second squad runs the pattern, troubleshoots a failure and knows who owns the next action.
AI contribution: Reuse evaluated assistance through supported interfaces; retain domain QA and developer accountability.
Accountability: QE platform product owner + supplier delivery lead

Q1, Q3, Q11

04 / A concrete reference architecture

A disposable test environment with durable evidence

The proposed API example uses a CI runner, real application and database software, and an owned HTTP provider substitute. The runner's assertions produce evidence; a separate integration lane tests what the substitute cannot establish.

Proposed test architecture for Our Banking Client. Blue runs real software, dashed gray marks the simulated provider and green retains evidence. Human review uses amber elsewhere; AI assistance uses purple. Arrows show selected calls and evidence handoffs, not live activity. Architecture explanation and sources

SYS Real systemsAI AssistanceREVIEW Human decisionPROOF EvidenceSIM Virtual serviceSTOP Failed check

Follow the environment from creation to cleanup

Proposed execution lifecycle. Numbered steps show order, not elapsed time.

1
Create and checkPin the build, tests and configuration. Provision supported resources and wait for health checks.
2
Seed and configureCreate isolated synthetic accounts. Load the owned, versioned virtual-provider behavior.
3
Execute and challengeRun required tests. The deliberate duplicate-posting variant must fail its independent assertion.
4
Retain and reviewKeep original assertions, setup diagnostics and run IDs outside disposable resources. Review omissions.
5
Clean up on every pathAttempt teardown after success or failure. Escalate failed cleanup to the named platform owner.
6
Reconcile integrationCheck the real provider and settlement separately. Contract drift triggers model review and rerun.

Evidence survives cleanup. A missing or failed required check holds the release.

CI owns execution and teardown; AI may draft a diagnostic summary. Test failures retain original assertions; setup failures retain diagnostics and skip execution. A failed cleanup needs an owner and escalation. Separate scheduled provider checks detect drift in the virtual-service model. Technical sources and assumptions.

Read the architecture without animation

A pinned test run calls the application. CI uses reviewed tests, fixture and dependency revisions. The example environment exists only for the bounded run.
The provider substitute exercises a fault. An owned HTTP model returns a deliberate delay or failure. This establishes behavior against that model.
The application writes real database state. The container runs the database engine. Independent assertions inspect transfer identity, journal entries and balances.
The runner retains original evidence. Assertions, logs and run versions survive cleanup. A failed check remains a failure; AI may summarize it but cannot turn it into a pass.
Real integration contributes separate evidence. Provider, device and settlement checks close the gaps left by substitutes. The accountable owner reviews all required results.

Lifecycle contract: the run manifest identifies the application commit, image references, tests, configuration, migrations, fixture seed and virtual-service revision. The platform owns runtime access and cleanup. Evidence is retained outside the disposable environment before it is removed. These are proposed implementation requirements. Q4–Q9

05 / Fit the application

Adapt the pattern to the application surface

API readiness, browser readiness and native mobile or batch readiness are separate questions. Choose a surface to see which parts of the architecture can be reused.

API and service tests

Java payment service with PostgreSQL and an HTTP provider dependency.

Execution and example stack: JUnit + REST Assured; Testcontainers-managed dependencies or a reviewed Compose stack. Use the existing container-capable CI runner.
Controlled dependency: WireMock models the HTTP provider. Run the real database engine where practical and use reviewed seed data.
Separate proof still required: Verify contracts where both sides participate, then retain actual provider and settlement checks. Inspect the transfer identity, journal and balances.
First practical increment: Reproduce PAY-142 with a pinned build, isolated account and a reviewed provider timeout.

Q4, Q6, Q7, Q8, Q10

Web and native mobile

React web and mobile clients use the same payment APIs, with different execution requirements.

Execution and example stack: Playwright can run web checks in a compatible browser image. Native mobile uses Appium drivers plus suitable devices or emulators and OS-specific tooling.
Controlled dependency: Virtualize backend or provider behavior at a controlled boundary. Do not substitute away the user journey the test is meant to exercise.
Separate proof still required: Keep the required browser/device matrix and real client-to-backend checks. A green API suite does not establish mobile readiness.
First practical increment: Automate one stable user journey; record browser/device, driver, application build and data revisions.

Q12, Q13, Q10

Legacy, batch and shared systems

Settlement files, proprietary middleware or licensed systems cannot necessarily be packaged as disposable containers.

Execution and example stack: Use a scripted VM, supported adapter, file harness or reserved integration window. Containerize only the compatible harness and surrounding dependencies.
Controlled dependency: Model the relevant file or message contract with a protocol-appropriate simulator. HTTP mappings alone do not cover every message or batch protocol.
Separate proof still required: Retain actual settlement-cycle, reconciliation and integration checks. Manage shared data and booking conflicts explicitly.
First practical increment: Control one input batch and its expected reconciliation, then reserve a reproducible validation window.

Q2, Q3, Q10

06 / Apply it to Our Banking Client

One payment journey before a 75-person rollout

Authored modernization roadmap and proposed architecture for Our Banking Client. The starting conditions and outcomes are illustrative, not an assessed client or a measured deployment. The starting point is heavy manual QE, few shared environments, no backend service virtualization and limited vendor test slots. The first target is PAY-142: a payment retry must not create a second transfer. The modernization work makes that outcome repeatable across engineers and runs.

Pin the runA developer and domain QA agree the expected transfer, journal and balance behavior. CI records the build and test revisions.
Provision and waitThe environment owner starts the supported application and dependency instances, applies migrations and waits for usable services.
Seed and modelUnique synthetic accounts and known balances are created. The integration owner reviews the provider delay, retry and duplicate-event cases.
Execute and challengeJUnit and REST Assured exercise the scenario. A deliberately duplicated transfer must fail the independent assertion.
Retain and reviewCI retains original assertions and diagnostic artifacts. AI may draft a triage summary; missing or failed checks remain unresolved.
Clean up and compareRemove run resources even after failure. Keep scheduled provider and settlement validation, then reproduce the run with another engineer.

This is a proposed implementation sequence, not a running payment integration. The page animation illustrates its relationships; it does not launch containers or execute the named frameworks.

Commercial implication. Price environment engineering, virtual-service fidelity, fixture maintenance, coaching and shared platform operation separately. The case's existing 480 setup hours are an illustrative allowance, not a quote for this modernization backlog. Sequence work by the constraint it removes and evidence it enables.

Track foundation improvement before attributing AI value

Record environment wait and setup time, reproducibility, non-product test failures, time to diagnose, dependency-model drift, cleanup failures and second-team onboarding. Then compare matched work with and without AI, including review and rework. Keep quality, coverage and escaped defects alongside capacity. Agree local targets from the observed baseline rather than inventing an industry savings rate.

Assess the environment prerequisites →Open the case implementation plan →Present the modernization story →

07 / Inspect the evidence

Primary-source library and interpretation

Reviewed 2026-09-07. Research synthesis supports the delivery practices; product documentation supports named capabilities. The roadmap, acceptance conditions and Our Banking Client implementation are authored proposals. Dates absent from a source are left unspecified. Download the source register CSV.

Q1 · DORA: Test automation

Reliable feedback, shared developer and tester responsibility, and incremental improvement of brownfield test suites.

Limit. Does not establish an AI productivity percentage.

Research synthesis · Reviewed 2026-09-07 · Source updated 2025-07-17

Q2 · DORA: Test data management

On-demand test data and controlled state support independent and parallel test execution.

Limit. Data availability does not prove business correctness.

Research synthesis · Reviewed 2026-09-07

Q3 · DORA: Continuous delivery

Delivery capability combines tests, deployment, data, observability and organizational practice.

Limit. CI installation alone is not continuous delivery.

Research synthesis · Reviewed 2026-09-07

Q4 · Docker Compose

Compose defines and runs multi-container applications in development and test workflows.

Limit. Packaging does not reproduce every production dependency or operating condition.