Start with useful assistance. Scale what teams can prove.
A Copilot license, a CI report assistant and a shared QE platform solve different problems. These four layers explain what changes in the work, what the AI may do and what leadership needs to see before expanding.
An authored leadership roadmap, not an industry-certified maturity model or an assessment of the client. The examples are target workflows; no adoption results are claimed.
01 / Assist → connect → delegate → scale
Four layers of AI-assisted QE
Increase integration, delegated actions and supported reuse only when the evidence justifies it. Teams may use several layers at once; broader agent authority is optional. Select a layer to follow the same PAY-142 payment retry scenario.
Shared foundations · start on day oneContext · data · reliable tests · CI · QE modernization · owners
Layer 4 supports layers 1–3. Scale useful assistance without having to delegate more actions.
1
One engineer or tester
Individual copilots
Draft test cases, test code and explanations in the tools people already use.
AI authority: The person chooses the task, supplies context and approves each change. AI output is a draft.
Input
Approved PAY-142 acceptance criteria, an existing Java test and synthetic account examples.
AI-assisted work
An engineer uses GitHub Copilot Chat to draft REST Assured/JUnit tests for the same-key retry. A domain tester can use an approved assistant to draft plain-language cases before learning test code.
Output and check
A reviewed case matrix or test diff. The engineer runs the tests and the domain owner checks the one-transfer outcome.
Accountable owner
QA lead and application engineer
Example technology
GitHub Copilot Chat + the existing IDE; REST Assured/JUnit for APIs, Playwright for web or Appium for mobile where those frameworks already fit.
Prerequisites
Approved AI access, usable specifications, independent expected results, example tests and reviewer time. Coding tasks also need a working local test command; drafting plain-language cases does not require containerization.
Evidence to expand
Compare equivalent tasks: accepted useful cases, total drafting plus review/rework time and detection of a deliberately injected defect. A green generated test alone is insufficient.
Next decision: Connect one repeatable workflow only after reviewed drafts add value and its required data can be accessed reliably.
Bring approved context and run evidence into a repeatable AI-assisted step.
AI authority: A fixed workflow retrieves approved inputs and drafts a report. It cannot edit tests, rerun a pipeline or change pass/fail results.
Input
An Azure Pipelines run ID, published JUnit results, sanitized traces and the reviewed PAY-142 contract.
AI-assisted work
A proposed read-only connector feeds the failed retry assertion and its evidence to an AI report assistant. The assistant groups failures, suggests a cause and identifies missing evidence.
Output and check
A triage brief with links to exact runs and assertions. The lead confirms whether the cause is a product defect, test issue or environment issue.
Accountable owner
QA lead with the DevOps engineer
Example technology
Azure Pipelines publishes JUnit results; a proposed adapter and approved model produce a separate AI brief. Azure's result publisher is a reporting source, not a built-in AI diagnosis service.
Prerequisites
Stable result formats, retained run artifacts, approved access, run-to-build traceability and a reviewed set of previous failures. Diagnosis-only scope can begin before automated repair is feasible.
Evidence to expand
Check diagnoses against resolved incidents, count unsupported claims and measure triage plus review time. Missing logs must produce an explicit evidence gap, not a confident conclusion.
Next decision: Consider a bounded agent only when one useful action can be isolated, permissioned, verified and stopped.
Let an agent choose approved steps, inspect results and prepare a candidate change.
AI authority: An enforced tool boundary allows a scoped branch edit and sandbox run. Attempt, time and spend limits stop the loop; merge and release decisions remain with people.
Input
A reviewed task, pinned build and test versions, known fixtures, an allowed tool list and explicit stop conditions.
AI-assisted work
The proposed agent inspects the PAY-142 failure, prepares a candidate patch and requests an isolated rerun. The runner verifies journal count and balances against the independently approved contract.
Output and check
A candidate pull request with its diff, test evidence and action history. Failed setup, insufficient evidence or exhausted limits stop the task for owner review.
Accountable owner
Application engineer, QA reviewer and platform operator
Example technology
An approved agent runtime + narrow repository/runner tools. GitHub Copilot cloud agent is one alternative for GitHub-hosted repositories; the Azure-based client scenario needs separately built and validated adapters.
Prerequisites
Reliable CI, isolated data, repeatable environments, versioned provider behavior, enforceable permissions, cleanup and a funded operator. WireMock and Testcontainers are options where the application and runtime support them.
Evidence to expand
Reproduce success and failure paths, demonstrate stop and cleanup, retain the original assertions and include review, reruns and operation cost. Reject changes that skip tests or weaken the financial expectation.
Next decision: Package useful patterns for reuse after the bounded workflow operates reliably. A shared platform may also scale layers 1 and 2 without enabling this layer.
Operate reusable AI and test services as a product for delivery teams.
AI authority: Platform services support layers 1–3. Each workflow retains its own action limits; wider distribution does not grant wider authority.
Input
Proven workflow packages, application contracts, approved models, evaluation cases and requirements from a second squad.
AI-assisted work
The platform team publishes versioned context adapters, prompts, evaluations, test environment/data services and evidence interfaces. Teams select supported patterns and supply their own business rules.
Output and check
A supported service catalog with onboarding, ownership, versioning, usage/cost visibility and upgrade checks. Payment and settlement squads retain distinct expected outcomes.
Accountable owner
QE platform product owner; application teams own domain outcomes
Example technology
Reuse existing repository and CI platforms; add shared connectors, prompt/model versioning, evaluations, telemetry and test services as needed. Kubernetes or a new portal is not a universal prerequisite.
Prerequisites
A funded service team, demand from more than one squad, agreed support and recovery expectations, compatible interfaces, evaluation ownership and capacity planning. A portal or tool license alone does not establish this capability.
Evidence to expand
Observe second-team onboarding, support effort, cost per accepted artifact, quality and repeatable operation. Compare against copying the workflow manually before expanding the service catalog.
Next decision: Expand to another journey only where its own prerequisites and value evidence support it. There is no universal date or requirement to reach every layer.
02 / Connect to the existing estate
Where each layer sits
Keep the current test frameworks and delivery system. Add the smallest connection that makes the selected workflow useful. These paths are a proposed integration design for Our Banking Client, an illustrative scenario.
1Individual copilots
Engineer + approved PAY-142
IDE assistant drafts a test
Reviewed diff + test run
2Connected workflow assistants
CI run + results + traces
Read-only AI report step
Evidence-linked triage brief
3Bounded QE agents
Reviewed task + tool scope
Permission gate + agent loop
Sandbox run + candidate PR
4Shared QE AI platform
Versioned context + templates
Models, evaluations + run services
Supported squad workflows
Independent checks + accountable ownersPreserve financial assertions; people approve merge and release.
Parallel integration paths, not four consecutive runtime steps. Layer 4 supplies shared services to layers 1–3.
The CI report stays separate from the deterministic pass/fail result. Agent requests pass through an enforced tool boundary; the model cannot approve its own permissions. Shared services version the context, prompts, models and evaluations while application teams retain their business rules.
A practical first move for 50–100 offshore QA staff
Start with the existing pilot team
For Our Banking Client, eight QA staff work within a 75-person organization. Begin with reviewed scenario/test drafts at layer 1 and one read-only CI diagnosis workflow at layer 2 where usable run evidence exists.
Leadership asks: Which repetitive task can we compare fairly? Who has time to review the result?
Fund the enabling work in parallel
Give the platform and DevOps owners a concrete backlog: test reliability, environment repeatability, data reset, provider virtualization and traceable results. If logs are missing, fix evidence collection before promising CI diagnosis. If environments cannot be reset, defer agent reruns.
Leadership asks: Which dependency blocks this workflow, who owns it and what does remediation cost?
Expand when the next boundary is proven
Permit layer 3 only for isolated actions with verified checks and stop conditions. Grow layer 4 when a second squad can onboard and operate a useful pattern. A shared platform can support copilots and reporting assistants while agents remain out of scope.
Leadership asks: Can another team repeat the result, with support and operating cost included?
Measure the work and the foundations separately
Track accepted output quality, total human effort including review and rework, elapsed waiting time, AI usage and shared operation cost. Treat modernization gains separately from incremental AI gains. Set acceptance thresholds with the client before comparison; these layers carry no fixed savings percentage or universal week count.
Foundations start on day one: approved context, independent expected results, reliable tests, fit-for-purpose environments, controlled data, CI evidence and accountable owners. Apply the prerequisites relevant to each workflow: a manual test-case draft and an autonomous sandbox rerun do not require the same infrastructure. Mobile devices, legacy interfaces and batch windows may change the route.
Start with the four-layer map, choose the client’s first useful workflow, then inspect its prerequisites. The executive slide explains progression; the technical slide explains the integration paths.
Primary product documentation reviewed 2026-09-08 supports the named capabilities below. The four-layer model, target architecture and expansion criteria are our synthesis. They are not vendor certification, a deployed integration or evidence of client savings.
GitHub: Writing tests with Copilot — Supports examples of generating and reviewing unit and integration tests. It does not establish client productivity or test completeness.
Microsoft: Publish Test Results v2 — Supports publishing JUnit and other result formats and attachments. The AI diagnosis adapter and workflow described here are proposed additions.
GitHub: About Copilot cloud agent — Supports the GitHub-hosted agent example and its customization. It does not establish a ready-made integration with the client's Azure stack.
GitHub: Copilot Agents application card — Describes agent capabilities and limitations, including the need to review and test generated changes. Our adoption gates are an authored QE proposal.