Job Description:

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, HONESTLY

The client could have left this out of the advert. They have chosen not to, because it is a real part of the job and finding out at offer stage helps nobody.

This is a defence client. Before any new technology goes into theatre, whether that is a vehicle, a weapon system or a piece of software, it goes through factory assurance testing: rigorous, formally documented testing against defined criteria with milestone sign-off. It is heavyweight, and the client does not get paid unless that documentation is a proper component of the test strategy.

Two things worth knowing. First, you will not be left alone with it; this is a small multidisciplinary team and the whole team contributes, engineering leadership included. Second, this is exactly the experience that makes defence test engineers hard to replace later in their careers. It is a genuine skill, and comparatively few people have it.

CLEARANCE

• SC clearance is required. Active clearance is strongly preferred on a contract engagement, though for the right person eligibility will be considered.
• Please read this carefully. Eligibility means a provable five-year UK address history. If you have lived outside the UK within the last five years, this will be difficult on this programme's timeline.
• A DBS check and BPSS clearance are not the same as SC. If that is what you hold, you are not yet cleared for this work.

LOCATION AND WORKING

• Remote across the UK. The client operates from multiple UK sites and hires nationally, so remote is the norm rather than the exception on this team.
• Occasional travel to a client site may be required, but this is not a requirement of the role day to day.

RATE

• Around £550 per day, negotiable. The client is open on rate for someone who genuinely has the Kafka and pipeline testing background.
• Two contract seats available on the programme.

PROCESS

Morela is managing this search on behalf of our client. Applications go to Adam Moore and are reviewed against the four requirements above first, so tell us about your Kafka work, the largest data volumes you have tested and how you approached it, and how you would build the test strategy here. Appointment is subject to references, security clearance and standard checks. Reasonable adjustments are available throughout.

For immediate consideration email (url removed)