Our Banking Client: strategic vision

75 offshore QA staff across five squads; 45 focus on manual and domain testing. Environments and vendor test slots limit parallel work.

451587

Manual & domain testing

45 people

Automation engineering

15 people

Data & environments

8 people

QA leads & coordination

7 people

The pilot draws eight QA staff from this population. More engineers alone do not create more vendor test capacity.

PAY-142 simulates a CAD 100 transfer accepted before a timeout. The customer retries; an injected duplicate-posting defect tests whether QE catches the second debit.

1. CustomerSend CAD 100
2. Payment APIKey: pay-142
3. ProviderAccept; response times out
4. Customer retriesReuse pay-142

Injected test defect2 journals

Payer CAD 800
Recipient CAD 200

FAIL · duplicate posting

Expected test outcome1 journal

Payer CAD 900
Recipient CAD 100

PASS · expected state

Expected: one transfer, one balanced journal and one customer-visible result. This is a QE test scenario, not a reported client incident.

Modelled hands-on effort for one bounded release test pack. Eight stages add to 300 hours.

Requirements

20h

Test design

40h

Test data

30h

Environment

25h

Automation

55h

Execution

80h

Triage & retest

35h

Release evidence

15h

The pack spans 10 business days. Waiting time and human effort use different units and must be measured separately.

Common context, fixtures and evidence serve every squad. Application teams retain business ownership.

Existing test frameworks and pipelines execute approved work. AI supports preparation and interpretation.

Establish the baselineActive work · vendor waits · coverage gaps

Prove repeatabilityEnvironment readiness · reruns · raw evidence

Isolate added AI valueCandidate acceptance · review · rework

Same payment scope. The two target states are proposed; no productivity or quality improvement has been measured.

The same tool creates different work in a shared manual environment and a repeatable delivery system.

These profiles illustrate effort, not adoption approval. Review twelve dependency areas before committing to scope, dates or benefits.

Mixed-maturity target: 300 hours becomes 222, including 40 hours of review.

Conditional capacity arithmetic; adoption prerequisites are unverified. Tool, cloud and vendor charges are excluded. This is not cash ROI or measured AI impact.

Owner	Accountability
Shared enablement	Own context adapters, templates, fixtures, runner integration and coaching.
Application QA teams	Own business scenarios, expected results, execution and defect disposition.
Product and release owners	Resolve requirement questions and accept the release evidence.
Delivery management	Provide repository access, overlap hours and an explicit backlog for freed capacity.

Reskill domain testers through paired reviews. Agree supplier incentives and reuse ownership before scaling.

Record actual pilot time from baseline through repeated API runs. Example windows remain subject to readiness.

Observation status: not yet recorded

1. Planning window · weeks 1–2

   Observe the baseline

   Record API test preparation, active effort, waits and rework for one comparable pack.

   Evidence gate: Reviewed API scope + usable baseline
2. Planning window · weeks 3–8

   Run the API pilot

   Record setup separately; measure review, execution, triage and retest over repeated packs.

   Evidence gate: Required assertions pass + comparable run evidence
3. Planning window · weeks 9–12

   Confirm repeatability

   Measure second-team setup, support effort and repeat runs before choosing the next scope.

   Evidence gate: Reusable pattern + evidence-based next step

Planning windows are illustrative. Environment, data, virtualization and reviewer readiness determine when each phase can progress.

Measure	Expansion evidence
Quality	All mandatory payment assertions pass; no unexplained skips or weakened checks.
Effort	Include preparation, review, correction, retesting and platform operation.
Delivery	Report elapsed time, waiting reasons and failed-run recovery separately.
Reuse	A second squad runs the pattern and maintains it without the pilot authors.

A faster draft is insufficient. Compare tasks of similar scope and retain conventional work as a reference.

The next decision: assess one payment workflow with QA, development and platform leads.

1. “Across the 75 QA staff, where do people spend time and where are they waiting?”
2. “Which payment journey has stable requirements, observable outcomes and an owner who can join a pilot?”
3. “Could one platform team remove duplicated work across the squads?”
4. “If we return capacity, which backlog or release commitment will use it?”

Agree the bounded pilot and its evidence before promising wider rollout. See the discovery brief for owners, commercial scope and timing.

Scope follows proven capabilityInputs + people + evidence + approved AI access + a measured baseline

Drafting

Reviewed scenarios

Approved rules and observable outcomes.

↓

Domain QA accepts the scenario matrix.Assess test design →

Diagnosis only

Evidence-linked triage

Retained failures, known dispositions and usable diagnostics.

↓

A reviewer checks the diagnosis; no retest runs.Assess diagnosis →

Execution

Reviewed test changes

Add repeatable environments, CI, fixtures, provider control and reliable runners.

↓

Independent assertions challenge the candidate.Assess automation →

Our Banking Client has not been assessed. The dependency backlog can change scope, cost and timing; the 480-hour setup allowance is not a client quote.

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

For Our Banking Client, fund repeatable payment tests and shared QE services alongside reviewed AI assistance. Validate this capability roadmap through client discovery.

Libra Internet Bank

35% less time

Test-creation timeIndex: previous time = 100

Previous 100

Reported 65

0100

UiPath customer case. Normalized from the reported reduction; review effort is unspecified. F1

Goldman Sachs

36% → 72%

Unit-test coverageShare of a selected module (%)

Before 36

After 72

0100

Diffblue customer case. Coverage measures exercised code; it does not establish financial correctness. F2

Fiserv

65% fewer incidents

Major incidentsIndex: previous year = 100

Prior year 100

Reported 35

0100

Tricentis modernization case. AI testing was a later pilot; this is not an AI-attributed reduction. F4

Peer results support a trial. Outcomes for Our Banking Client remain unmeasured.

Requirements ready

Onboarding design

Draft scenarios in the current test-management workflow.

Proof

Accepted coverage and measured review effort.

Execution repeatable

Payment API tests

Generate candidates in the existing framework and CI pipeline.

Proof

Correct behavior passes; a known fault fails.

Diagnostics available

Failure triage

Draft diagnoses alongside the existing disposition process.

Proof

Faster correct decisions with traceable evidence.

Choose one entry point, validate its prerequisites and agree how reviewers will judge the result. Wider rollout depends on local evidence.

1. 1Assist a person Individual copilotsCopilot drafts a retry test; QA reviews and runs it. Proof to expandUseful, correct drafts after review
2. 2Assist a workflow Connected workflow assistantsA CI assistant explains failures with links to evidence. Proof to expandTraceable, useful recommendations
3. 3Delegate a bounded task Bounded QE agentsAn agent drafts a patch and reruns sandbox tests. Proof to expandRepeatable actions within limits
4. 4Scale proven capability Shared QE AI platformSquads reuse context, evaluations, fixtures and evidence. Proof to expandA second team can adopt and operate it

Shared foundations · start on day oneContext · data · reliable tests · CI · QE modernization · owners

Authored roadmap. Expand with validated prerequisites and client evidence.

QE modernization: isolated runs and controlled dependencies. AI assistance: preparation and interpretation.

Starting point: heavy manual QE and scarce vendor environments. Pilot target: controlled service tests, with real integration still required.

Business aims: fewer escaped payment defects and emergency fixes. These proposed pilot measures do not establish those outcomes.

PAY-142 is an authored scenario. Each AI output needs review; test runners execute and people decide.

Illustrative artifacts and outcomes. Preserve failed evidence; a passing retest alone does not approve release.