QA Tester - **Must have Active SC Clearance**

QA / Test Engineer

READ THIS BEFORE YOU APPLY

You will be testing Kafka-based streaming data pipelines at genuinely enormous scale, and you will be writing the test strategy for the whole programme from a blank page. There is nothing in place today. If that sounds like the job you have been waiting for rather than a job with a gap in it, keep reading.

WHO THE CLIENT IS

Our client is a UK-headquartered AI company building sovereign AI capability for defence and national security. They have been established for around a decade and are one of the country's leading builders of AI for high-risk, high-assurance environments.

Their platform is an AI operating system built entirely in the UK, designed for settings where security, trust and full infrastructure control are non-negotiable. It deploys across cloud, edge, on-premise and fully air-gapped systems, and is already live inside UK Defence and national security missions.

They closed a substantial Series A round recently, hold a significant government framework position, and are scaling engineering and delivery across the UK. Full details of the client are shared with shortlisted candidates.

THE PROGRAMME

The client is standing up a new twelve-person team across two work streams, delivering a major UK defence programme through a larger prime contractor. The team is being built from scratch, and this role sits in it from day one.

One of those work streams is a data management system ingesting enormous volumes of highly varied data: IoT sensors in the water, weather feeds, transponder data from ships. Streaming, continuous, and at a scale where millions to potentially billions of rows a day is the normal operating picture, not the stress test.

Kafka, high-volume ETL and ELT pipelines, and a blank page where the test strategy should be. That is the job.

WHAT YOU WILL ACTUALLY DO

• Test the pipeline, not the page. Own quality across large-scale Kafka streaming and batch data pipelines: ingestion, transformation, reconciliation and output.
• Build the test harnesses. Work directly alongside the data engineers to design and build the harnesses that make this system testable at scale. This is a build role as much as a test role.
• Prove it at volume. Prove correctness, completeness and integrity across volumes where sampling and eyeballing stop working and you need a genuine strategy.
• Build the CI safety net. Design and build the automated regression suite that runs on every release and proves accuracy, stability and response times have not moved.
• Own the strategy. Write the test strategy for this programme. There is a blank page here and the client wants someone who has an opinion about what goes on it.
• Own the assurance evidence. Prepare and complete formal test documentation for defence factory assurance: what was tested, how, against which criteria, signed off at each milestone.
• Muck in. This is a small, multidisciplinary team in a scaling business. Everyone gets hands on, including the engineering leadership.

THE FOUR THINGS THAT DECIDE THIS ROLE

The client has been clear about what they need. These four are not preferences, they are the job.

• 1. Hands-on Kafka. Topics, partitions, consumer groups, offsets, replay, schema registry. Streaming is the architecture of this programme, not an adjacent interest.
• 2. Testing high-volume ETL or ELT data pipelines. Millions of rows a day and upward, in a system real users depended on, and you can explain how you did it rather than which tools you held.
• 3. Writing the test strategy. There is nothing in place on this programme yet. They want someone with a clear view of what to test first, where the risk sits in streaming data, and how to sequence and evidence it.
• 4. Modern architecture. REST, contract testing, schema validation. This is a greenfield build and legacy-only API experience will not translate.

ALSO REQUIRED

• Automated regression testing in CI: repeatable suites that run on every release and check accuracy, stability and response times. Not one-off manual runs over chunked data.
• Comfort working close to data engineers, in the pipeline itself rather than at the UI layer, and building the tooling that makes testing possible.
• Python and SQL, and a structured, evidence-led approach: defined criteria, traceability, and the discipline to document what you did and why.
• Someone who can operate in a small team where the boundaries are loose and the standard is high.
• SC clearance, or genuine eligibility for it. Active clearance is strongly preferred on contract. See the note below, because this catches people out.

WHAT THE TECHNICAL INTERVIEW WILL PROBE

• How you tested a pipeline, not just that you did. Which technologies, how you handled schema and schema changes, and how you proved it held at volume. Naming tools is not the same as describing an approach.
• What runs in your CI when a release goes in. Splitting a large load into chunks and working through it is data processing. What matters here is the automated suite that catches a regression in accuracy or response time the moment a new release lands.
• How you would build the test strategy here. What you would test first, what the risks are in streaming data, how you would sequence it and how you would evidence it.
• What your frameworks buy this programme in speed and confidence, rather than a list of what you have used.

THE DOCUMENTATION, HONE