QA Engineer

Mission:

We are looking for someone to work out how quality engineering should work when a team delivers this fast, and then build it.

We make mission-critical software for unmanned systems, used in maritime search and rescue and in defence. Operators depend on it under pressure, often at the edge of a link. When it is wrong, it is wrong in front of someone who needed it to be right.

We also move quickly, and AI tooling is deeply embedded in how our engineers work. That combination is the problem this role exists to solve: verification has to scale at the same rate as delivery, and it cannot scale by adding reviewers. It has to be engineered, and most of that engineering has not been done yet, here or anywhere else.

So this is not a role with a playbook. We are less interested in how many years of a particular tool you have than in how you think about problems like this one and how you go about solving them.

What You’ll Do:

• You reason about the problem rather than applying a process. There is no established practice to import here. We need someone who works out what verification should look like for this situation, from first principles, and can explain why.

• You are open to changing how the work gets done. Including your own way of working. Treat "this is how QA is normally done" as a starting hypothesis rather than a conclusion, and be ready to throw parts of it away when they stop making sense.

• You go looking for problems. The gaps in a quality system are rarely written on a ticket. We need someone who finds them, sizes them, and comes back with a proposal, rather than waiting to be pointed at the next thing.

• You push rather than follow. This role exists to change how an engineering team works, which means disagreeing with people who are busy and confident. If your instinct when something looks wrong is to raise it and argue it through, you will do well here.

• You prefer evidence to habit. "We have always done it this way" and "it looks fine to me" are both answers you should find unsatisfying. When you claim something is safe, you should want a number or a failing test behind it.

• You are comfortable without a map. You would be inventing some of this, getting some of it wrong, and iterating in the open rather than waiting until it is polished.

What We’re Looking For:

• Work out what should be verified, and how. Start by understanding the platform properly: its workflows, its real-time behaviour, its failure modes. Then decide where the risk actually is, which is rarely where the existing tests are.

• Build test generation pipelines, and make them check themselves. The core of the job. Pipelines that produce tests are easy; pipelines whose output you can trust are not. That means mutation testing that proves a suite detects real regressions, assertion analysis that fails a suite for looking green without proving anything, and tests derived from specification rather than from implementation.

• Engineer against correlated blind spots. AI-generated code and AI-generated tests can share the same blind spot and agree with each other about the wrong thing. Structure things so verification is genuinely independent, and prove the independence holds.

• Make the product mechanically verifiable. Build the testability and the harnesses that let a pipeline drive and assert against the application reliably, and hold a defensible line between what is worth driving through the UI and what belongs a layer below.

• Solve the oracle problem. Much of what we ship is not a return value. It is a rendered map, a decoded video frame, a telemetry overlay with a hard freshness budget, a screen coordinate converted to a position on the ground. Turning "an operator can see that it is right" into an assertion a machine can make is one of the more interesting problems here.

• Own the gates, and keep them honest. Decide what mechanically blocks a merge or a release, and revisit it as volume rises, because a gate that is easy to satisfy has stopped being a gate.

• Verify more than correctness. A series of individually correct changes can still walk a design somewhere expensive, and a review that only asks "is this change correct" will wave every one of them through. Noticing that class of problem is explicitly part of this job.

• Measure the process, not just the product. Rework rate, escaped defects, gate effectiveness, how long the tenth similar feature takes compared with the first. Then change something because of what the numbers say.

Why Join Us:

• Be part of an innovative team working on a cutting-edge WPF desktop application.

• Opportunity to enhance your skills in automation, process improvement, and documentation.

• Collaborate with a talented, supportive team dedicated to delivering high-quality software.

• Make a direct impact by improving application quality and streamlining workflows.

• If you’re detail-oriented, passionate about quality, and eager to improve both software and processes, we’d love to hear from you!

Do you want to know more about us ?

Visit our LinkedIn page at https://www.linkedin.com/company/tekever/