Talk

Before I worked in software testing, I was an aircraft engineer in the Royal Air Force. One of the first things you learn in that environment is that quality isn’t something you add on at the end — it’s how you work, all the time. In the RAF, quality shows up in very practical ways. You follow the procedure because it exists for a reason. You have to account for your tools; you get your work checked by someone else, you write things down so they can be traced, audited, and understood later. And when you sign something off, you’re putting your name against it — personally & legally. That creates a very different relationship with quality than ticking a box or chasing a metric or trying to hit some deadline. This talk is about how that mindset carries directly into software testing.

I use a simple engineering example from my time in the RAF — routine gearbox oil servicing on a Eurofighter. On the surface, it sounds trivial, but it’s tightly a controlled, heavily documented, independently checked piece of work, and it’s treated with the same seriousness as any more complex mission-critical task. The lesson I am hoping to get across is straightforward: there are no “just” jobs when it comes to quality matters. From there, I try to draw clear parallels with testing, test readiness is the equivalent of pre-task checks, peer review and layered testing mirror independent inspections done on aircraft. Test evidence and defect logs play the same role as maintenance records, QA sign-off and release decisions aren’t about ceremonies that “have to happen” — they’re about accountability that’s intended to generate a level of confidence in the work that’s been done.

The talk breaks this down into four simple pillars that hold quality up: standards, checks, traceability, and learning, which is built upon the real foundation underneath all of it which is culture. In the RAF, you didn’t just follow the rules because someone is watching, or your client expects it of you or the contract requires it — you follow them because you believe in why they exist. I also bring this together through my usual Stoic Tester lens: control what you can, accept what you can’t, respond clearly when things go wrong, and learn from every mistake. That way of thinking has shaped how I approach testing, leadership, and quality in complex systems, while in the RAF and now.