We needed proof that automation could support the next release cycle, not another framework experiment.
Head of Quality
The client had a stable web product and a growing regression scope, but no automated suite. They asked a1qa to choose one business-critical area, establish a client-owned foundation, and prove that accepted tests could enter their repository and CI/CD workflow with measurable delivery and quality controls.
The challenge
Manual regression testing for the selected scope required about 3 working days and 12 person-days per release. The team planned 2 releases per month, but repeatable checks consumed time that QA engineers needed for exploratory testing and new features.
The provider had identified 240 regression testing scenarios across user provisioning, role-based access, subscription changes, billing handoffs, and core APIs. They did not want a pilot that counted generated scripts while leaving review, maintenance, and CI integration unresolved. The outcome had to be a bounded set of accepted tests, with clear traceability and a quality signal the product team could use.
a1qa used an assessment-to-pilot delivery model. The project ran for 10 weeks with 2 automation engineers, 1 senior quality engineering architect, and a part-time delivery lead. The experts leveraged Playwright and TypeScript for web tests, REST clients for API checks, and GitHub Actions for CI execution.
First, the team mapped the manual regression testing workflow, reviewed the repository and CI path, and ranked the 240 candidate scenarios by business impact, repeatability, data needs, and automation feasibility. The engineers defined what counted as an accepted test: approved traceability, framework compliance, human review, stable repeated execution, and usable CI evidence.
Second, a1qa created an agreed open automation foundation in the client’s repository. The team established project structure, reusable components, data setup, environment configuration, reporting, selector guidance, assertion patterns, and pullrequest checks.
Third, the specialists implemented AI to accelerate scenario normalization and repetitive code preparation. The engineers reviewed every test against the framework conventions and business intent. Automated checks detected structural problems, duplicated logic, and missing traceability before pull request review.
Finally, a1qa ran accepted tests in the client’s CI/CD workflow. The team repeated the suite across the agreed validation window, tracked flaky results, separated environment and product failures, and recorded manual corrections, so the workflow could improve without accepting output automatically.
The pilot included user provisioning and role-based access, subscription lifecycle and billing handoffs, and selected core API workflows. It did not attempt to automate the provider’s whole regression scope.
How acceptance worked
A generated draft became an accepted test only after it passed the agreed code checks, linked back to an approved scenario, underwent human review, and ran repeatedly in CI. The team recorded rejected patterns and manual corrections instead of hiding that work inside the final count. This made delivery lead time and engineering effort comparable with the original manual process. It also protected the 65% critical scenario result from being inflated by unfinished scripts. Product defects and environment failures were reported separately, so they did not become test maintenance work by default.
At handoff, the client received the source code, configuration, review checklist, CI instructions, assumptions log, and prioritized extension backlog. Ongoing managed operation remained a separate decision.
