What Apollo 13 can teach us about quality engineering

Success begins long before launch

When asked about the Apollo 13 mission, most people will think of the words ‘Houston, we have a problem’ – and perhaps the extraordinary ingenuity, resourcefulness, resilience, bravery and skill that solved that problem, allowing three NASA astronauts to return to Earth alive.

Engineers, however, may also find themselves considering NASA’s extraordinary pre-mission preparation – because they know that without it, the teams that provided that ingenuity, resourcefulness, resilience, bravery and skill would not have been in place and prepared to act.

The oxygen tank failure that crippled the spacecraft happened almost 200,000 miles from Earth. There was no possibility of sending replacement parts, no emergency patch to deploy and no option to restart. Every decision carried the additional weight of being impossible to unmake.

And yet, precisely because the mission had been engineered to cope with that level of unpredictable failure, Apollo 13 can now be considered one of NASA's greatest successes.

By the time of launch, thousands of hours had been invested in design reviews, simulations, inspections and rehearsals. NASA understood they could never foresee every failure mode, so they built systems, processes and teams capable of responding effectively to any unexpected event. That’s a fundamentally different objective from trying to prevent all failures – and a distinction that matters in software delivery just as much as it did in space exploration.

Too often, software quality is still treated as something that happens near the end of delivery – testing as a final inspection before release. In reality, confidence is built throughout the lifecycle. Every design decision, code review, automated test, environment check and performance assessment contributes to the likelihood of a successful outcome. A successful production release is rarely the product of a great testing phase. More often, it’s the result of hundreds of sound engineering decisions made weeks or months before.

Testing should challenge assumptions, not confirm them

One of NASA's defining strengths was its willingness to question its own assumptions. Mission simulations deliberately introduced unexpected failures. Engineers rehearsed scenarios they hoped would never happen, knowing that reality rarely follows the happy path and that discovering a gap during a simulation is considerably less costly than discovering it in flight.

That’s the mindset that should be applied to the design of your testing programme. If it’s primarily structured to confirm that expected behaviour works, it’s providing reassurance rather than confidence. Reassurance is comfortable; confidence is earned. It comes from understanding how your systems behave when their assumptions prove incorrect – when an external service becomes unavailable, when transaction volumes significantly exceed forecast, when the application encounters corrupted or incomplete data. Those questions often reveal far more about operational readiness than another successful execution of a predefined test script, and they are the questions that a well-designed testing programme should be asking by default.

Resilience is designed in, not discovered later

One of the reasons the Apollo 13 astronauts survived was redundancy. Critical systems had backups. Alternative procedures existed. The crew and Mission Control had genuine options when their original plan was no longer viable – which meant a catastrophic failure was a solvable problem.

Some organisations still view this kind of redundancy in software delivery as unnecessary cost. Duplicate environments, regression suites, monitoring platforms and resilient infrastructure can appear expensive when everything is working normally, and it’s tempting to defer that investment until it becomes obviously necessary. The difficulty is that it usually becomes obviously necessary at the worst possible moment. Quality engineering is not simply about preventing defects from reaching production. It is about ensuring that when failures occur, as they will, they remain manageable rather than escalating into business-critical incidents. For financial services firms – with customers expecting round-the-clock services and regulators demanding operational resilience – that capability needs to be designed in from the start, not retrofitted after a production incident has already happened.

Evidence over expectation

One of the most striking aspects of Apollo 13 Mission Control’s response to the oxygen tank explosion was its level of discipline. No major decision was based on optimism or instinct. Every recommendation was supported by telemetry, calculations and observable evidence – including the difficult decisions, where the evidence pointed away from the preferred course of action.

Technology leaders face equivalent decisions before every significant release. Should they proceed? Should they delay? Has risk been reduced to an acceptable level? These questions deserve better than subjective assessments, and quality engineering provides the means to answer them properly – through defect trend analysis, test coverage data, performance results, operational readiness indicators and production monitoring. The most effective go/no-go conversations I see in financial services firms are the ones grounded in that kind of evidence, where the team can point to specific data and say with genuine confidence that they understand the risk they are accepting. Building the capability to have those conversations consistently is one of the most valuable things a quality engineering function can do for your organisation.

Collaboration solved the problem

Popular accounts of Apollo 13 tend to celebrate individual brilliance, but the reality was even more impressive. The mission was saved by teams of specialists combining their expertise under pressure, challenging each other's thinking and working through problems that had never been encountered before. No lone engineer, however talented, could have brought that spacecraft home.

Modern software delivery works similarly. Quality is not the sole responsibility of the testing team, and treating it as such is one of the most reliable ways to ensure it remains a problem. Developers, architects, operations specialists, product owners and quality engineers all contribute to the reliability of what gets delivered. The organisations that consistently deliver dependable software are rarely those with the largest testing teams. In fact, they’re the ones that treat software quality as a shared responsibility from the outset. They’re the ones that share the asking of ‘how will we know this works?’ questions amongst everyone involved in building that software rather than leaving it to a separate team at the end of the sprint.

Customers remember the outcome

Apollo 13 launched successfully. But it’s the landing that history remembers.

Your customers judge your software in exactly the same way. They are unlikely to recall whether your deployment completed on schedule or whether every release activity followed the documented process. However, they will remember whether or not they could access their accounts, whether or not payments completed as expected and whether or not the service was available when they needed it. From their perspective, quality is measured through experience rather than process, and a single significant failure can erode trust that took years to build – a dynamic that’s particularly acute in financial services, where the link between technology reliability and customer confidence is direct.

And that is why quality engineering should remain focused on business outcomes rather than technical milestones. The goal is a service that works reliably for the people who depend on it, not a clean test report.

Bringing these principles into your delivery programme

Few organisations operate in environments as demanding as space exploration. But your financial services firm faces a version of the same expectation. Your customers and regulators expect your systems to work – and that if failures do occur, your firm will contain them swiftly and respond to them quickly enough for confidence in your firm to feel completely justified.

Apollo 13 reminds us that engineering excellence is not demonstrated by everything going according to plan. It is demonstrated when preparation, discipline and collaboration allow teams to respond effectively when reality refuses to follow the script. The organisations that manage such situations well are not the ones that test the most. They are the ones that have embedded quality thinking into their delivery process at every stage – from the earliest design decisions through to the moment a release goes live.

Building that kind of capability is not primarily a question of tools or frameworks. It is a question of where quality thinking enters your delivery process, who is accountable for it and whether the evidence it generates reaches the people who need to act on it. Those are the questions worth asking – and before your next release rather than after it.