Why spacecraft software testing is a different discipline
When a web service crashes, you roll back a deployment. When a spacecraft flight computer crashes over the far side of the Moon, you may not talk to it again for hours, and by the time you do, thermal margins, attitude drift, or a stuck thruster valve may have made the fault permanent. That asymmetry, no second chances, no live debugger, no observability agent you can install in flight, shapes how testing is done for spaceborne software. It is why an entire discipline of verification and validation (V and V) exists specifically for flight systems, and why the test team on a mission is often as large as the flight software team itself.
Spacecraft software testing in 2026 is not just "unit tests plus integration tests". It is a layered campaign that starts with mathematical models of the vehicle and its environment and ends with the actual flight computer running actual flight code, wired to actual sensors and actuators on an air-bearing table or in a thermal-vacuum chamber. Between those endpoints sit distinct test modes with their own tooling, their own bug classes, and their own cost per test hour. Knowing which mode catches which bug, and in what order to run them, is the core skill of a spacecraft V and V engineer.
The economic argument is blunt. A bug caught in MIL (model-in-the-loop) costs an engineer-hour. The same bug caught in HITL (hardware-in-the-loop) costs a shift on an occupied testbed plus a config change plus regression re-runs, often days. The same bug caught in flight costs a mission anomaly review, potentially a safe-mode entry, and in the worst case the mission itself. The purpose of the V-model is to push defects as far left as possible, catching them in the cheapest possible environment before they compound.
This article walks the full test chain from requirements through flight, section by section. It explains the four in-the-loop modes (MIL, SIL, PIL, HITL), the fault-injection and off-nominal campaigns that sit on top of them, the tool ecosystem (Trick, Basilisk, cFS Bundle Tests, LabVIEW real-time, PLEXIL, EDGE), and the career path that leads from junior test engineer to V and V lead. If you are targeting a role in flight software, testing is not a fallback, it is often the fastest path into the industry, because good verification engineers are chronically scarce.
The V-model and why it still governs flight software
The V-model is the reference lifecycle for safety-critical embedded systems. On the left leg of the V, you decompose: mission requirements become system requirements, which become subsystem requirements, which become software requirements, which become module designs, which become code. On the right leg of the V, you verify by mirror image: unit tests verify modules, integration tests verify subsystem behavior, system tests verify software against software requirements, and acceptance tests verify the delivered system against mission requirements. Each right-side activity has a corresponding left-side artifact it is testing against.
The reason the V-model survives, despite four decades of methodology fashion, is traceability. In flight software you must be able to answer, for every requirement, "which test proves this?" and for every line of code, "which requirement justifies you being here?" Standards like ECSS-E-ST-40C in Europe and NASA-STD-8719.13 in the United States make this bidirectional trace mandatory for Class A and Class B software. A CI pipeline that runs 12,000 tests is worthless if you cannot map those tests back to the requirements they cover.
Modern flight programs adapt the V-model rather than replace it. Agile-style iterations happen inside a phase: you might do sprint-length loops during detailed design and coding, but the phase gates (PDR, CDR, TRR, FRR) remain waterfall milestones with formal review boards. The V-model does not forbid iteration, it forbids skipping the artifacts that let auditors reconstruct what you did and why. In practice this means every test in your suite has an ID, a linked requirement, a pass criterion written before the test was executed, and a signed record of the run.
Where the in-the-loop test modes fit is on the right leg of the V. MIL tests the design model against system requirements. SIL tests the generated or hand-written flight code against software requirements, still in simulation. PIL tests the code running on the target processor, catching compiler, timing, and memory issues. HITL tests the integrated system against system and mission requirements with real hardware in the loop. Each ascends the V toward the top-right corner where the fully integrated spacecraft meets the mission it was built to fly.
A useful mental model: MIL asks "is the algorithm right?", SIL asks "is the code right?", PIL asks "does the code run right on this processor?", HITL asks "does the whole system behave right when the real world pushes on it?" Skipping a layer does not save time, it just moves the bugs to the layer above, where each bug costs 10x more to find.
MIL: model-in-the-loop with Simulink and Basilisk
MIL is where testing starts, before a single line of flight code exists. The controller, estimator, or autonomy logic is expressed as a mathematical model, typically in MATLAB and Simulink, or in a Python-based astrodynamics framework such as Basilisk from the University of Colorado. That model is exercised against a plant model of the spacecraft dynamics: rigid-body attitude, orbital mechanics, actuator dynamics, sensor noise characteristics. The whole thing runs in non-real time on an engineer's laptop.
The purpose of MIL is to answer algorithm-level questions. Does the attitude control law stabilize the vehicle within the required pointing budget? Does the Kalman filter converge under expected sensor noise? Does the guidance law hit the target state within propellant budget? At this stage you are not asking whether the code is correct, you are asking whether the underlying design is correct. Bugs caught here are design bugs, and they are the cheapest bugs on the whole V.
Basilisk deserves specific mention because it has become a de facto reference environment for academic and small-satellite MIL work. It provides Python-scriptable modules for spacecraft dynamics, gravity models, reaction wheel and thruster actuators, star tracker and IMU sensor models, and Monte Carlo campaign infrastructure. A team can stand up a credible attitude control MIL test in days, not months. For larger primes, Simulink remains dominant because auto-code generation from Simulink to C is a mature, DO-178C-qualifiable toolchain.
MIL testing lives or dies on the fidelity of the plant model. A perfect controller against a bad dynamics model just proves you understand your own math. Serious MIL programs invest heavily in validated plant models: multi-body dynamics that capture flexible modes, sensor models that reproduce real bias, drift, and misalignment characteristics, and disturbance models (aerodynamic drag at low altitude, solar radiation pressure, magnetic residual dipoles) tuned against on-orbit data from prior missions. "Garbage in, garbage out" is not a slogan here, it is the primary failure mode of MIL campaigns.
Monte Carlo is the workhorse of MIL. A single deterministic run tells you the nominal case works. A 1000-run or 10,000-run Monte Carlo, varying initial conditions, sensor noise seeds, actuator misalignments, and mass properties within their uncertainty envelopes, tells you the design is robust. Modern MIL frameworks parallelize these runs across cluster nodes and summarize results with 3-sigma envelopes on state variables of interest. When a Monte Carlo shows a 1-in-500 case where pointing drifts outside spec, you have found a design margin problem before any code was written.
SIL: software-in-the-loop, code without hardware
SIL is the first mode that tests actual flight code. The C or C++ implementation of your control law, estimator, or command handler runs in a simulation harness on a workstation, wired to the same plant model you used for MIL. If your MIL was in Simulink, the auto-generated C code from the model replaces the Simulink block in the simulation loop. If your flight software is hand-written in cFS (NASA's core Flight System) or a proprietary framework, the flight modules link against a simulated environment layer that stubs the hardware APIs.
SIL catches a different bug class than MIL. Integer overflow in a computation that worked fine in double-precision Simulink. Fixed-point rounding artifacts. Off-by-one errors in indexing. State machine transitions that never fire because a guard condition was mistyped. Buffer boundary bugs. Uninitialized memory. Race conditions between tasks (if the SIL harness supports realistic threading). These are code-level bugs, and they are invisible to MIL because MIL never runs the code.
The cFS Bundle Tests project is worth knowing if you work in the NASA ecosystem. It provides a SIL harness for the cFS framework, letting you exercise apps like the Command Ingest, Scheduler, Data Storage, and Housekeeping apps in a simulated environment with scripted command sequences and expected telemetry checks. Building on cFS Bundle Tests, teams write mission-specific test scripts that command the software through nominal and off-nominal scenarios and assert on telemetry values, event messages, and internal state.
SIL is where the CI pipeline lives. Every commit to the flight software repo triggers a SIL run: unit tests, integration tests, and a curated set of scenario tests. On a well-run program, this pipeline runs in under 30 minutes and blocks the merge if anything fails. Coverage tooling (gcov, LDRA, VectorCAST) reports statement, branch, and MC/DC coverage against DO-178C or ECSS levels. Static analyzers (Coverity, Polyspace, LDRA) run in parallel and flag rule violations against MISRA-C or the JPL Power of Ten.
SIL scales in ways HITL cannot. You can run 100 SIL scenarios in parallel on a cluster in the time it takes to run one HITL scenario on a physical testbed. This is why serious programs push as much test coverage as they can into SIL, reserving HITL time for tests that specifically require real hardware behavior. The tradeoff is that SIL never catches bugs that only manifest with real timing, real bus contention, or real sensor pathologies. Those wait for PIL and HITL.
PIL: processor-in-the-loop, real silicon in the loop
PIL inserts the actual flight processor into the simulation loop. The flight code, compiled for the target architecture (RAD750, LEON3, LEON4, RISC-V variants like Microchip's PIC64-HPSC, or ARM Cortex-R variants on newer platforms), runs on either a physical single-board computer or a cycle-accurate emulator such as TSIM for LEON. The simulation of the spacecraft and its environment still runs on the workstation, but sensor and actuator I/O is routed to the flight processor over a debug link, typically Ethernet or a serial connection.
PIL catches the bug class that lives at the intersection of code and silicon. Compiler optimization bugs that make code behave differently at -O2 than at -O0. Endianness bugs when the target is big-endian and your development host is little-endian. Timing bugs where a control loop that meets its 10 ms deadline on your x86 laptop misses it on a 200 MHz LEON3 with the cache disabled. Stack overflow bugs that show up because the flight compiler generates deeper stack frames. Floating point discrepancies where the flight FPU rounds differently. These bugs are undetectable in SIL because SIL is not running on the target.
A well-instrumented PIL setup also gives you the first honest measurement of CPU margin. You compile the flight image, load it onto the target, run a representative workload, and measure how much CPU headroom you have. Flight programs typically require 50 percent margin at CDR, dropping to 25 percent at delivery. If your PIL numbers show you at 80 percent CPU load under nominal conditions, you have a serious design problem, because off-nominal conditions (fault handling, high telemetry rates, autonomy recovery sequences) always burn more cycles.
Memory margin gets measured the same way. Static analysis tools tell you your worst-case stack depth, worst-case heap usage, and image size. PIL confirms these numbers on the real toolchain. Programs that skip PIL and go straight from SIL to HITL routinely discover, late in the schedule, that their flight image is 15 percent over the available flash or that their worst-case stack exceeds the allocated size. Both problems are expensive to fix at that stage because they often force architectural changes.
PIL is also where you first exercise the flight software's boot sequence, its interaction with the boot loader, its reaction to power cycles, and its recovery from watchdog resets. These are notoriously fault-rich areas because they are hard to test in SIL (the simulation is always running, it never truly boots). Teams often find their first serious flight software bugs during PIL boot testing, weeks before HITL is scheduled to begin.
HITL: the full hardware-in-the-loop testbed
HITL is where testing becomes physical. The flight processor, the real avionics bus (SpaceWire, MIL-STD-1553, CAN, or increasingly TSN Ethernet on modern platforms), real (or engineering model) sensors and actuators, and often the real power distribution unit are wired together in a lab environment that emulates the spacecraft. A real-time simulator, typically running on a QNX, VxWorks, or Linux real-time kernel with LabVIEW real-time or Trick as the framework, provides stimulus and captures response at hard real-time rates.
HITL catches the last major bug class: integration bugs. Timing between subsystems that assume different clock synchronization models. Bus contention that shows up only when three subsystems try to publish at once. Sensor pathologies (a real star tracker occasionally emits a corrupted quaternion, a real IMU has a startup transient, a real reaction wheel has stiction near zero speed) that no simulation captures faithfully. EMI-induced bit flips. Thermal effects on oscillator drift. Grounding loops. HITL is the first test mode where the software encounters the physical world, and the physical world is always weirder than the model.
Trick, from NASA Johnson, is the reference framework for high-fidelity real-time HITL simulation, historically for human spaceflight programs. It provides a scheduling core, distributed simulation over IP, and integration with common test hardware. EDGE (Engineering DOUG Graphics for Exploration) provides visualization. Together they form the backbone of Orion, Gateway, and commercial crew HITL environments. On the smallsat and commercial side, LabVIEW Real-Time on National Instruments PXI chassis is common because the hardware is turnkey and the FPGAs let you emulate exotic sensor interfaces without custom ASICs.
HITL testbeds are expensive and scarce. A single HITL rack at a small satellite company might cost 500,000 to 2 million euros in hardware plus a full-time engineer to maintain it. Prime contractor testbeds for crewed programs run into tens of millions. Access is scheduled, contested, and audited. This is the operational reality that drives the entire left-side push of testing: every hour you can catch a bug in SIL is an hour of HITL time you did not have to book.
HITL is also where you validate ground segment interaction. The mission operations console commands the flight software through the same telecommand path it will use in flight, receives telemetry through the same downlink path, and the operators practice contingency procedures on realistic hardware behavior. Ops training and HITL testing are often the same activity in the final months before launch. A HITL campaign that finds a flight software bug that would have caused a safe-mode entry three days after launch has paid for the testbed by itself.
Fault injection and off-nominal campaigns
Nominal-case testing proves the software works when nothing goes wrong. Off-nominal testing proves it survives when things do. A serious flight software V and V campaign spends more effort on off-nominal cases than nominal, because on-orbit anomalies are almost never nominal. The Ariane 501 loss, the Mars Climate Orbiter loss, the Mars Polar Lander loss, the Schiaparelli loss, all traced to conditions that were not in the nominal envelope.
Fault injection is the systematic technique for off-nominal testing. You take the simulation (at any level from MIL to HITL) and deliberately corrupt it. Inject a stuck-at-max sensor reading. Inject a delayed telecommand. Inject a bus timeout. Inject a memory bit-flip via a debug interface. Inject a reaction wheel that reports zero torque when commanded to spin up. Then observe: does the flight software detect the fault, isolate it correctly, and recover to a safe state? If it does not, you have found a fault management gap.
Fault injection is organized around a Failure Modes and Effects Analysis (FMEA). The FMEA lists every credible failure mode of every component, the effect that failure has on the vehicle, and the mitigation (autonomous or ground-commanded). The V and V team's job is to write a test for every FMEA row and show the mitigation actually works. On a smallsat program this might mean 200 fault injection cases. On a crewed vehicle it can mean tens of thousands.
Off-nominal timing is a subclass worth calling out. Real spacecraft experience clock jumps (leap seconds, GPS rollover, ground time updates), variable-latency telecommand receipt (during eclipse, during high solar activity), and sudden bursts of high-rate events (during a maneuver, during a payload observation). Testing these correctly requires the simulator to be able to warp time, drop packets, and reorder events. Trick and LabVIEW real-time both support this. Ad-hoc SIL harnesses usually do not, which is why timing anomalies are a persistent late-stage discovery.
A well-run off-nominal campaign also includes double-fault and cascade cases. What happens when the primary IMU fails during a maneuver AND the backup star tracker is temporarily blinded by the Sun? What happens when a reaction wheel saturates AND the magnetorquer used for desaturation has already failed? Real anomalies are often cascades, not single points, and fault management logic that handles single points fine can loop, thrash, or deadlock under cascades. For teams moving from web-scale QA into flight software testing, our guide to transitioning from manual QA to test automation covers the mindset shift, and the more general programming and testing pillar at Refonte Learning connects test discipline across domains.
Autonomy testing: PLEXIL, state machines, and the combinatorial explosion
As missions push further from Earth, on-board autonomy grows. A rover at Mars cannot wait 20 minutes for a ground-in-the-loop decision when it sees an unexpected obstacle. A lunar lander in terminal descent cannot uplink for permission to switch to a backup landing site. Autonomy software, whether expressed as goal-oriented planners, hierarchical task networks, or explicit state machines, presents unique testing challenges because its behavior depends on state that ground operators cannot fully predict.
PLEXIL (Plan Execution Interchange Language), developed at NASA Ames, is one framework specifically designed with testability in mind. Plans are expressed as hierarchical node trees with explicit start, invariant, end, and post conditions. This structure lets you generate test cases systematically: for every node, exercise the paths where each condition succeeds and fails. Coverage becomes measurable in a way that ad-hoc state machine implementations do not permit.
The fundamental problem with autonomy testing is combinatorial explosion. A state machine with 20 states and 50 transitions has more reachable configurations than you can enumerate in HITL. Coverage-guided fuzzing, adapted from security research, has started to appear in autonomy testing: the fuzzer perturbs inputs and rewards paths that reach unexplored states, hunting for unreachable-in-theory configurations that turn out to be reachable in practice. This is early technology in the space sector but growing.
Formal methods play a supporting role. Model checkers such as SPIN, NuSMV, and Kind2 can prove properties of state machine designs before they are coded, catching classes of bug (deadlock, livelock, unreachable state, forbidden state) that testing cannot exhaustively catch. Formal verification does not replace testing, it complements it: formal methods prove the design, tests prove the implementation matches the design.
Simulation replay is another useful autonomy testing tool. Whenever an on-orbit anomaly occurs, you replay the exact telemetry sequence into the SIL, HITL, or PIL environment and confirm the flight software behaves as it did on orbit. This becomes the regression test for that anomaly and prevents its recurrence in future missions. Programs with strong replay discipline build up, over years, a library of hundreds of anomaly regressions that pay dividends across missions.
The tool ecosystem: what practicing V and V engineers actually use
The testing stack in a spacecraft software team spans a handful of dominant tools, most of which a working engineer will touch. On the modeling and MIL side, MATLAB and Simulink dominate at primes; Basilisk, GMAT, and Python-based astrodynamics libraries dominate at newer smallsat companies and academic groups. On the SIL side, cFS Bundle Tests, Google Test, CTest, and mission-custom Python harnesses are common. On the PIL side, TSIM for LEON, QEMU with target extensions, and vendor emulators for RAD750 or specific ARM parts show up regularly.
HITL is the most heterogeneous layer. NASA and its primes rely heavily on Trick with EDGE for visualization. Commercial and smallsat companies frequently use LabVIEW Real-Time on NI PXI hardware because the ecosystem is turnkey and integrators know it. European programs often use the EGSE (Electrical Ground Support Equipment) tools produced by Terma, Rovsing, or in-house at ESA. Regardless of the framework, the pattern is consistent: real-time OS, deterministic scheduler, hardware I/O to the flight hardware, replay and capture of all bus traffic.
On the analysis and reporting side, requirements management is dominated by IBM DOORS (or DOORS Next), Polarion, and increasingly Jama Connect. Traceability from requirement to test to test result is maintained in these tools and audited at every review board. Bug tracking uses Jira, GitLab, or mission-specific tools; the key is that every bug has an ID, a severity, and a resolution status that is reviewed weekly by a Change Control Board.
Static analysis and coding standards enforcement rely on LDRA, Polyspace, Coverity, and Klocwork. MISRA-C, JPL Power of Ten, and NASA CFS coding conventions are the usual rulebooks. Coverage measurement uses VectorCAST, LDRA, or gcov depending on qualification requirements. For DO-178C DAL-A software or ECSS Category A software, you will need MC/DC coverage measurement, which is a specific and narrow tool market.
CI infrastructure is increasingly cloud-hybrid: Jenkins, GitLab CI, or GitHub Actions runners orchestrate SIL runs on cloud compute, while PIL and HITL runs execute on scheduled physical testbeds. The trend in 2026 is toward digital twin infrastructure, where a full simulation of the vehicle runs continuously in the cloud, alongside the physical testbed, and both are commanded from the same operations console. This lets ground operators rehearse contingencies against digital twins without booking scarce HITL time, and it lets V and V engineers regression-test against the twin nightly.
The career path: from junior test engineer to V and V lead
Spacecraft software V and V is one of the most reliable entry paths into flight software. The reason is supply: there are more people who want to write flight software than people who want to test it, even though good V and V engineers are as scarce and as valued as good flight coders. Hiring managers know that a junior engineer who can write a clean SIL test case, chase down a fault injection failure, and produce a defensible test report is worth more than a junior engineer who can only prototype algorithms.
Entry-level V and V engineers typically start at 55,000 to 75,000 euros in Europe, or 85,000 to 110,000 USD in the United States, depending on employer and location. Primes and NASA centers pay somewhat below the top commercial employers (SpaceX, Blue Origin, Rocket Lab, and the well-funded smallsat companies) but offer more structured progression and better long-term security. A detailed spacecraft software engineer salary breakdown covers the numbers by region and seniority.
Mid-career, typically 4 to 8 years in, engineers specialize. Some become deep experts in one test mode (the HITL specialist who owns the testbed, the fault injection lead who owns the FMEA-to-test mapping, the autonomy verification engineer who owns the PLEXIL environment). Others become generalists who own an entire subsystem's test campaign end to end: attitude control V and V lead, GNC V and V lead, command and data handling V and V lead. Salaries at this stage typically land at 90,000 to 140,000 euros or 130,000 to 180,000 USD.
V and V lead is the senior individual contributor endpoint, typically 10 to 15 years in. The V and V lead owns the entire verification strategy for a mission or product line: which requirements get verified at which level, how much HITL time is budgeted, how the regression suite is maintained, and how test results are presented at review boards. They interact daily with systems engineering, safety, and mission assurance. They often testify at test readiness reviews and flight readiness reviews. Compensation at this level is 150,000 to 220,000 euros or 200,000 to 300,000 USD at major primes and top commercial employers.
The management track branches off at any stage. Test engineering managers own headcount, budget, testbed capital planning, and staff development. It is a different skill set. If you enjoy solving the technical puzzle of "why did this test fail?" more than the organizational puzzle of "how do I staff three test campaigns with two engineers?", stay on the IC track. If you find yourself constantly redesigning the team's workflow, management may fit. Refonte Learning covers the branching decision in our flight software engineer vs spacecraft software engineer comparison and our practical how to become a spacecraft software engineer guide.
How to build a portfolio that gets you hired into V and V
Breaking into spacecraft V and V without prior flight experience is possible if you build a portfolio that demonstrates the specific skills the field values. First, pick an open source flight software framework and build a test campaign against it. cFS is the obvious choice: it is open, it is used on real missions (LRO, MMS, Orion crew module, Lunar IceCube, dozens more), and the cFS Bundle Tests project gives you a starting harness. Fork it, add missionlike scenarios, and publish your work on GitHub.
Second, learn one MIL environment well. Basilisk is the fastest ramp because it is Python, it is free, and the documentation includes worked examples. Build a Monte Carlo attitude control test campaign for a small satellite: 1000 runs, varying inertia tensor uncertainty, sensor noise, and initial attitude error, with 3-sigma envelope plots and a written test report. That single project demonstrates you understand MIL fidelity, Monte Carlo design, and V and V reporting discipline.
Third, get exposure to real-time software. Take a Raspberry Pi or a BeagleBone, install a real-time Linux kernel (PREEMPT_RT) or FreeRTOS, and write a simple control loop that meets a 10 ms deadline with measurable jitter. Instrument it. Report the timing distribution. This shows you understand what "real-time" actually means, which is a prerequisite for HITL work and something most software engineers cannot do.
Fourth, write. Publish a blog post or technical write-up on a specific verification topic: how MC/DC coverage differs from branch coverage, why fault injection is harder than fault detection, what boot-time testing looks like on a flight processor. Hiring managers read these. A candidate who can articulate a verification concept clearly in writing is one who can produce a defensible test report, and defensible test reports are the currency of the discipline.
Fifth, get one certification if you can. ECSS certification training, INCOSE CSEP, or a DO-178C awareness course from a recognized training provider all signal you understand the standards environment even before your first job. None of these substitute for hands-on experience, but they clear you past the resume screen at conservative employers.
The Refonte Learning spacecraft software engineering program is structured around building exactly this portfolio: hands-on flight software work in cFS, MIL and SIL campaigns in Basilisk and Simulink, real-time exercises on target-representative hardware, and a mentored capstone that produces a defensible verification report you can put in front of a hiring manager. It is designed for career-switchers and new graduates who want a credible on-ramp into the discipline.
Common failure patterns and how good teams avoid them
After observing dozens of programs, a handful of failure patterns show up repeatedly in spacecraft software V and V. Naming them helps you avoid them.
The first is late HITL. A program spends 18 months in SIL, then discovers at first HITL power-on that the bus timing assumptions were wrong, or the boot sequence has issues, or the sensor drivers do not handle the real sensor's startup transient. Six weeks of schedule vanish in the recovery. The fix is early PIL: get the flight code onto flight processor as soon as one exists, even if the surrounding hardware is not ready, because the code-processor interactions are the biggest bug reservoir and take the longest to drain.
The second is FMEA drift. The FMEA is written early, fault injection tests are written against it, and then the design evolves and the FMEA does not. Six months later the tests are exercising failure modes that no longer exist and missing failure modes that were introduced. The fix is to make FMEA maintenance a formal step of the change control process: no design change ships without a corresponding FMEA review.
The third is regression starvation. The team writes tests as they go, but never invests in making the regression suite fast, stable, and trusted. Eventually the suite takes 12 hours to run, has 40 flaky tests, and no one trusts the results. Merges happen without running it. Bugs escape. The fix is to treat the regression suite as a product: dedicated ownership, flakiness budget, hard wall-clock target, and a policy that failing tests block merges without exception.
The fourth is anomaly amnesia. An on-orbit anomaly happens, the team debugs it, ships a patch, and moves on. No regression test is written. Two years later the same class of bug recurs on a different mission. The fix is a mandatory anomaly-to-regression-test rule: no anomaly is closed until the corresponding regression test exists and passes on the fixed code.
The fifth is over-reliance on the star engineer. One senior V and V lead knows every detail of the testbed, every trick of the fault injection framework, every historical anomaly. Then they leave. The next mission stumbles for a year. The fix is written documentation, pair-testing culture, and rotation so that at least two people can operate any critical testbed. This is a management discipline, not a technical one, and it is the one most programs fail at.
Ready to work on real spacecraft software
Spacecraft software testing is a discipline in its own right, with its own tool ecosystem, its own career ladder, and its own economics. It rewards engineers who are methodical about traceability, comfortable at the boundary between software and hardware, and stubborn about off-nominal cases. It is one of the few areas in software where the best test engineers are as valued as the best coders, and where entry-level opportunities open faster for testers than for developers.
If you are ready to build the portfolio and skills that flight software teams hire on, the Refonte Learning spacecraft software engineering program gives you the hands-on flight software, MIL, SIL, and HITL experience, plus a mentored capstone, that shortens the path from career start to your first real launch. Refonte Learning has trained engineers now working across smallsat operators, primes, and space agencies. Testing spacecraft software is one of the highest-leverage engineering skills you can build in 2026, and it is a skill you can start acquiring before you have ever touched flight hardware.