QA & Software Testing for Aviation

Key Aviation testing & engineering challenges

• Bidirectional traceability from system requirements through code to test cases and results must survive years of change, audits, and supplier handoffs.
• Structural coverage gaps have to be explained, not just closed — dead code, deactivated code, and unreached branches each demand a different justification.
• Test tools that reduce or automate a DO-178C objective can pull tool qualification under DO-330 into scope, changing the economics of automation entirely.
• Robust space and time partitioning under ARINC 653 must be demonstrated by test, since one overrunning partition collapses the whole assurance argument.
• Airline operational systems face brutal, weather-driven demand spikes during irregular operations, exactly when rebooking and crew tools must not fail.
• Passenger and airline platforms integrate decades-deep legacy — PSS, GDS, and fixed-format message interfaces — where interface contracts drift silently.

Standards & regulations we test against

What does DO-178C actually require from software testing?

DO-178C assigns every airborne software component a design assurance level from A to E, derived from the severity of the failure condition it could contribute to — catastrophic at Level A, hazardous at B, major at C, minor at D, and no safety effect at E. That level sets how much verification you owe, and it is not something to renegotiate late in a programme. Testing must be requirements-based rather than exploratory: every case traces to a requirement and forward to its result, and the structural coverage achieved by that requirements-based testing is then measured — statement coverage at Level C, decision coverage added at Level B, and modified condition/decision coverage at Level A.

The consequence is that testing produces evidence, not just green builds. Coverage shortfalls have to be explained rather than closed by convenience: dead code is removed, deactivated code is justified with a rationale for why it cannot execute in the target configuration, and unreached branches are traced back to requirements too weak to drive a test. All of it is reviewed. Any tool leaned on to reduce, automate, or replace a DO-178C objective — a coverage analyser, a test-case generator — may itself require qualification under DO-330, which means an automation decision is quietly also a certification decision.

How do avionics platforms and interfaces shape the test approach?

Software levels do not appear from nowhere. ARP4754A, revised as ARP4754B in December 2023 alongside ARP4761A, describes how aircraft and system development allocates development assurance levels to functions and items, with the safety assessment process — functional hazard assessment, fault tree analysis, common cause analysis — supplying the reasoning. Testing inherits its rigour from that allocation, so a verification plan written without reference to the safety assessment tends to over-test benign items while under-testing the few that carry the argument. Reading the allocation before writing the plan is usually the cheapest optimisation available to an aviation test team.

Platform architecture then shapes the mechanics. Integrated modular avionics hosts applications of different software levels on shared hardware, and ARINC 653 defines the space and time partitioning that keeps them apart — so robust partitioning must be demonstrated by test rather than inferred from a configuration table, because a partition that overruns its window or reaches another's memory invalidates the assurance argument for everything sharing that processor. Interfaces deserve the same scepticism: ARINC 429 traffic is fixed-format and label-driven, so range, sign, staleness and refresh-rate handling need explicit cases. Security overlays all of it, which is why security testing belongs in the plan early.

Where does aviation software testing extend beyond the cockpit?

Only a fraction of an airline's software is airborne. Passenger service systems, IATA NDC offer and order APIs, ancillary retailing, crew rostering and pairing, MRO and maintenance planning, baggage reconciliation, cargo, and disruption management make up the bulk of the estate, and they fail in ways that stop operations rather than aircraft. None of that falls under DO-178C. Ground systems supporting communication, navigation, surveillance and air traffic management fall under DO-278A with its AL1 to AL6 assurance levels, while retailing, loyalty and back-office platforms fall under neither. Knowing which line a system sits on is a budget decision before it is an engineering one.

On the commercial side the pressure is operational. A storm front or an airspace restriction turns a quiet afternoon into a rebooking surge, and reaccommodation, crew legality checks and passenger notification are exactly the systems judged in that hour. Performance work therefore models disruption rather than average traffic, with concentrated bursts against rebooking and refund paths and realistic throttling when a GDS or payment processor slows. Correctness under load is the harder half: double-booked seats, duplicated refunds and duty-time violations appear when retries multiply, so performance testing only helps when paired with idempotency assertions and the date, timezone and multi-currency cases that ordinary functional testing under-covers.

Where does an independent QA partner genuinely fit in aviation?

Honest scoping first, because in this sector an overstated capability is a programme risk rather than a marketing detail. Certification credit for airborne software rests with the applicant and their designated engineering representatives or Organization Designation Authorization; no testing vendor can grant it, and a supplier offering to certify avionics software is describing something that does not exist. Teams building DAL-constrained airborne code should engage a partner running a qualified certification pipeline, with the tool qualification and liaison history that DO-178C evidence demands, and carry that evidence through their own authority. Appsierra holds neither DER nor ODA authority and does not certify aircraft or avionics.

The rest of the estate is where independent pods earn their place, and it is the larger part of aviation software spend: airline and airport enterprise platforms, passenger-facing web and mobile, retailing and NDC integrations, crew, MRO, baggage, cargo and disruption tooling, plus the non-certified ground and back-office systems around them. Verification support inside a customer-owned certification programme is workable too — test automation, traceability tooling and requirements-based test authoring executed under the customer's process, plan and authority, with the certification argument staying theirs. A risk-free pilot is the sensible way to test that boundary; scope it with our engineering team first.