{"id":1235,"date":"2026-10-21T04:40:00","date_gmt":"2026-10-21T04:40:00","guid":{"rendered":"https:\/\/aircrafto.com\/blog\/?p=1235"},"modified":"2026-10-21T04:40:00","modified_gmt":"2026-10-21T04:40:00","slug":"testops-primer-glossary-aviation","status":"publish","type":"post","link":"https:\/\/aircrafto.com\/blog\/testops-primer-glossary-aviation\/","title":{"rendered":"TestOps for Newcomers: A Primer With a Glossary"},"content":{"rendered":"

My first instructor had a saying about checklists: a checklist you don’t trust is worse than no checklist, because it teaches you to stop looking.<\/em> She was talking about preflight, but she could have been talking about software. Programmers keep checklists too \u2014 automated tests that run over every change before it ships \u2014 and somewhere along the way, many teams stopped trusting their own. The response to that problem has collected under a young name, TestOps<\/strong>, and this primer walks through it the way I’d walk a new student through the hangar: plainly, with a glossary at the end and no shame about asking what the words mean.<\/p>\n

TestOps, explained from the preflight ritual<\/h2>\n

Think about what a preflight inspection actually produces. Not a repaired aeroplane \u2014 a decision<\/em>: airworthy or not, made quickly, made the same way every time, and trusted enough that nobody re-checks the fuel sample out of fear. Now picture the opposite: an inspection that flags a phantom oil leak every third walkaround. Pilots start skipping steps. That is precisely the situation many software teams are in \u2014 their automated checks cry wolf so often that engineers re-run them without reading \u2014 and it is the situation TestOps sets out to fix.<\/p>\n

The definition worth memorising: run the test suite the way you would run any critical service. The people it serves are developers; what it sells them is a trustworthy go\/no-go answer for each change, delivered while they still remember what they changed. The Ops Atlas overview of TestOps<\/a> is the best one-stop reference I know, and it makes a point worth repeating: the discipline is not about owning more tests, it is about whether each verdict deserves belief. Notice the aviation parallel \u2014 nobody praises a safety program for the thickness of its manuals, only for what its go\/no-go decisions are worth.<\/p>\n

Weight and balance for test suites<\/h2>\n

Every student pilot learns that loading is a design problem: too much weight in the tail and the aircraft behaves badly at altitude. Test suites have their own loading problem. The classic healthy shape \u2014 most checks fast and cheap at the bottom, a few slow end-to-end journeys at the top \u2014 is called the test pyramid, an idea Mike Cohn wrote about back in 2003. Load the wrong end and you get the famous anti-pattern: suites dominated by slow, moody interface tests that take hours and fail for reasons no one can reproduce. Practitioners call that shape the ice-cream cone, and it wobbles exactly the way the name suggests.<\/p>\n

Newer shapes exist \u2014 the honeycomb and the trophy, which shift weight toward tests around a system’s middle layers \u2014 and partisans argue about them the way pilots argue about high-wing versus low-wing. The honest answer from the field: pick by cost and by how reliably each layer gives the same answer twice, not by which diagram is fashionable. A shape is airworthy if the verdicts coming out of it are.<\/p>\n

A mini-glossary before you go solo<\/h2>\n

Flight training works because the syllabus gives every manoeuvre a name, a standard, and a way to fail it honestly. Software teams kept the checking habit and lost the vocabulary, which is half the reason their meetings go in circles. Here is the vocabulary that comes up in every TestOps conversation, translated out of jargon:<\/p>\n