The Spec-to-PR Pipeline: Bypassing Legacy QA with Spec-Driven Automation

Background

The challenge

• No automation existed - no framework, no pipeline, no reporting. Everything verified before a release was verified by hand.
• No stack decision had been made either. The client wanted a formal, documented evaluation before a single line of test code was written.
• The inherited backlog of ~300 cases had never been written with automation in mind. Many were incomplete, ambiguous, or untestable as written.
• The domain was heavy. Designing meaningful tests meant understanding SIRET flows, solvency scoring logic and legal-announcement monitoring - not just clicking through a UI.
• Test cases were managed in Squash TM and heavily parametrized, with 2 to 11 parameters per case, which made keeping the tool and the codebase in sync a problem in its own right.

Our approach

• Ran a formal evaluation of three candidate stacks - JavaScript/TypeScript with Selenide, Java with WebDriver, and JavaScript/TypeScript with Playwright - and recommended Playwright for its built-in parallelism, auto-waiting, native TypeScript support and community momentum, with the honest caveat that this was a greenfield decision to be validated iteratively rather than a guarantee.
• Built the automation system from scratch: project structure and configuration, environment handling, a Page Object Model layer, Playwright fixtures, and reusable helper utilities.
• Defined a smoke suite early, ahead of broad coverage, so stakeholders had something fast and visible to trust while the rest of the suite was still being written.
• Designed and implemented a GitLab CI/CD pipeline in parallel - trigger rules, artifact uploads for reports, screenshots and videos, secret management, timeout handling, and environment-specific configuration.
• Reviewed the inherited manual test cases end to end after the lead architect raised concerns about their quality: assessing coverage, rewriting weak cases, and mapping each one against actual system behaviour rather than assumed behaviour.
• Stepped up as acting lead QA when the project's lead QA fell ill mid-engagement. Scope expanded rather than paused, and reporting moved to a senior QA lead with no domain knowledge of the platform - which meant translating SIRET flows, solvency scoring and legal-announcement monitoring into clear sprint deliverables and status updates.
• Investigated the Squash TM sync problem, where parametrized cases did not map cleanly between the test management tool and the Playwright codebase, and formulated a data sync plan.
• Built an LLM-assisted test generation workflow iterating from a VSCode plugin to the OpenCode CLI for tighter control. Given a test case spreadsheet exported from Squash TM, the model generates the corresponding Playwright code - page objects, fixtures, helpers - then validates its own output against a defined checklist before the PR is raised. That cut the distance from test specification to PR-ready code significantly.

Working against the grain

• Process integration was the part that did not land. The plan was to wire the suite into the sprint and release cycle with defined trigger points, enforcement gates, and results feeding into the release decision.
• Multiple attempts were made to establish that. The product team dismissed the initiatives, did not follow up on communication, and showed no appetite to change a release workflow they were already comfortable with.
• The integration stayed incomplete - not for lack of effort or planning, but for lack of cross-functional support. A gate nobody agrees to enforce is not a gate, and automation nobody has agreed to act on cannot carry release confidence on its own.
• The suite kept running and kept reporting regardless, and the defects it surfaced were raised through the normal channel.

Results

• Roughly 100 -> 800 parametrized test cases automated~~, each tests parametrized with 2 to 11 variants~~, multiplying effective coverage well beyond the raw case count.
• Automated regression testing introduced where none had existed before - baseline, tooling and process established from zero.
• A fully operational GitLab CI/CD pipeline with artifact management, secret handling and environment-specific configuration.
• Dozens of bugs reported across the engagement, several of them critical defects fixed before release.
• A reviewed and rewritten manual test suite, mapped against real system behaviour instead of inherited assumptions.
• An LLM-assisted test generation workflow that other teams inside the client organization adopted and extended, adding intent tables to select which rules and skills the model applies per situation.

Key technologies and deliverables

Automation framework

Playwright (TypeScript), Page Object Model, fixtures

CI/CD integration

GitLab CI/CD - artifacts, secrets, environment configs

Test management

Squash TM - parametrized cases, sync plan

LLM tooling

GLM model via API, OpenCode CLI, VSCode plugin

Test design

Parametrized cases, 2-11 parameters each

Coverage

Early smoke suite plus automated regression suite