Senior/Middle QA

We are re-platforming a national public-sector system in the EU

: ~750 screens of a legacy client-server 4GL (Uniface), rebuilt as a modern Java/Spring + React application on top of an Oracle database.

The hardest question on this project is not "does the new code work" - it is "does the new system do exactly what the old one does"

. Every migration wave has to clear that bar before it goes live. At 750 screens and thousands of business rules, that cannot be proven by hand - it has to be proven by a test system

: an automated, repeatable verification machine that compares old and new on every wave.

That machine does not exist yet. You build it.

You design the test architecture, you set up the AI-driven workflow that turns business rules into executable tests at scale, you lead two QA/BA engineers who work inside that system, and you make the go / no-go call for every wave. You work from the specification owned by the BA Lead - and you send it back when it is not testable.

What you will do

●       Design and build the test system from the ground up

— the automation framework (API and UI), the test data strategy, the parity-comparison engine that runs the same scenario against the legacy system and the new one and diffs the results, and the CI pipeline that runs all of it per wave.

●       Build the AI-driven QA workflow

— an AI-first pipeline from business rule → test case → automated test → execution report. Use AI coding agents to generate and maintain test code. You own the prompts, the guardrails, and the review step that keeps AI output trustworthy.

●       Own the test strategy

— decide what gets tested, at which level (API, UI, data), with what data, and what blocks a release. Set it once for the program and adapt it per wave.

●       Own the quality gate for each migration wave

— define the exit criteria, run the verification, and make the go / no-go call on whether the new system matches the old one. Your word decides whether a wave ships.

●       Lead the QA function

— two QA/BA engineers report to you. You assign work, prioritize, review test code and coverage critically, and grow them into automation and AI-assisted testing.

●       Turn the BA Lead's specification into a test oracle

— read each business rule, decide how it will be proven, and send it back when it is ambiguous. On this project the specification and the test oracle are the same artifact, so you and the BA Lead work as a pair.

●       Verify parity against the legacy system

— screen by screen and record by record, including direct data checks in Oracle, and make every difference visible and explainable.

●       Own UAT execution and defect triage

— plan the UAT sessions with the client together with the BA Lead, run them, and drive defects through to closure and sign-off.

●       Keep everything traceable

— every test maps back to a business rule, a screen, and a wave, generated and maintained by the system rather than by hand. Public-sector delivery is audited; the traceability matrix is a deliverable, not paperwork.

What we expect (must-have)

●       5+ years in QA / test automation on complex business systems, including 2+ years leading a QA team or function

— you have owned a release decision, not just executed a test plan

●       You have built a test automation system before, not just used one

— framework design, test data management, reporting, CI integration; you can show something you designed from zero that a team then worked inside

●       Hands-on automation depth

— Playwright, Selenium, REST Assured, Postman/Newman or similar, plus solid programming in at least one of Java, TypeScript or Python; you write and review test code daily

●       AI-first way of working, proven in QA

— you already use AI coding agents (Claude Code, Cursor, Copilot or similar) to generate and refactor test code, LLMs to derive test cases from requirements, and you know where they fail: you have built prompts, review loops and guardrails around them, and you can tell a good AI-generated test from a plausible-looking wrong one

●       Test strategy ownership

— you have decided what gets tested, at which level, and what blocks a release, and defended that decision to a client or a delivery manager

●       Strong SQL

— you check data in Oracle yourself rather than asking a developer to check it for you

●       Experience leading a small QA team

— task assignment, prioritization, code and coverage review, mentoring engineers into automation

●       Strong English

— you will run UAT with the client, write test strategy documents, and report readiness to an international public-sector client

Nice to have

●       Agentic / MCP-based test tooling

— e.g. Playwright MCP, browser agents for exploratory testing, LLM-based visual or output comparison, self-healing locators

●       Data comparison / reconciliation tooling

— comparing large Oracle datasets between two systems, golden-record approaches, record-level diffing at scale

●       Experience with a legacy migration

— parallel run, cutover, wave-based rollout, or reconciliation between an old and a new system

●      CI/CD experience — GitLab CI, Jenkins or similar, running suites on OpenShift / Kubernetes

●      Contract and API testing at scale (OpenAPI-driven test generation, consumer-driven contracts)

●      Accessibility testing against WCAG — it is a legal requirement for EU public-sector systems

●      Performance testing basics (JMeter, k6 or similar)

●      Domain knowledge in social insurance (or pensions, benefits, other public-sector welfare systems)

Why this role is interesting

●       You build the machine, not just the tests.

The test system is a product in its own right — the thing that lets a national system be migrated wave by wave without a big-bang cutover — and it is yours to architect.

●       AI-first QA with real stakes.

This is not a pilot: 750 screens and decades of business rules are the scale at which AI-generated tests, AI-assisted triage and automated parity checking stop being nice-to-have and become the only way to deliver. You define how it is done here.

●       You make the call the whole project is judged on.

Parity with the legacy system is the acceptance criterion for a national system — and deciding whether it has been met is your gate.

●       A specification worth testing against.

The BA Lead owns the business rules, so you spend your time proving them, not inventing them — and you have a direct line to fix the ones that are not testable.

●       Short decision path.

You work directly with the project's PIC / product engineer and the BA Lead — no layers between you and the decision.

●       Long-horizon project

— a multi-year modernization program, not a three-month body-shop gig.

Tech stack

●       The domain:

public-sector social insurance agendas — pensions, benefits, contributions

●       The legacy source of truth:

a Uniface client-server 4GL application, largely undocumented, still in daily production use

●       The new system:

Java/Spring backend over a frozen Oracle PL/SQL API, React SPA frontend, Keycloak, OpenShift

●       Your test system (you choose, we expect roughly):

Playwright for UI, REST Assured / Postman-Newman or similar for API, a parity-comparison layer over Oracle, Jira / Confluence + Xray or TestRail for traceability, all wired into CI and run per wave

●       Your AI toolchain:

AI coding agents (Claude Code or similar) for test generation and maintenance, LLM-driven scenario and edge-case derivation from specifications, AI-assisted failure triage — with human review as the gate

●       Owned by your team:

the automated regression suites, the parity-comparison engine, and the traceability matrix together with the BA Lead

Working setup

●       Client contact:

direct - you run UAT with the client and report wave readiness yourself, alongside the BA Lead

●       Working language:

English