A two-person software team with a 12-month delivery schedule can realistically assign 100 to 200 engineering hours to verification before integration testing starts. Choosing how to spend them is its most consequential V&V decision. Distributing hours across every module yields shallow coverage everywhere. Focusing on the wrong modules yields deep coverage of low-value areas. Neither tradeoff serves the mission.
Begin With Interfaces
When you have limited testing hours, verifying ICD-defined interfaces offers the greatest return. Interface defects are not necessarily the most frequent flight software defects. They are costly because late discovery is expensive. Finding a packet encoding error during integration, with hardware assigned and the subsystem team waiting, can cost a week of rescheduling. Finding it in unit testing on a development laptop costs an afternoon.
For packet-focused flight software, the ICD specifies every interface requirement: fields, data types, offsets, and valid ranges. Testing an encoder against those definitions maps directly to a stated requirement. A passing test verifies it. A failure narrows the defect to that field's encoder. The verification-to-localization tradeoff is favorable.
In practice, an ICD with 25 packet types averaging 15 fields each yields about 375 field-level verification requirements. Manually testing all of them is substantial but feasible. Mechanical generation from the ICD field table is much faster, provides equivalent coverage, and allows regeneration after ICD changes.
Test Boundaries Before Nominal Paths
When you have limited testing hours, nominal-path tests deliver less value than boundary tests. A nominal test checks expected behavior under normal conditions. That matters, but an approximately correct implementation will often pass such tests immediately, yielding little information. Boundary tests probe specified edges where defects cluster: minimum and maximum values, maximum plus one, and maximum minus one.
For a 16-bit unsigned field valid from 0 to 65535, the four highest-value checks encode 0, encode 65535, and verify behavior at 65536 and the native data type's raw maximum. They take minutes to write and expose many off-by-one, truncation, and type-conversion errors in the encoding path. Adding 20 arbitrary mid-range nominal tests increases the count but yields less additional defect-finding value.
State and Mode Logic
Most flight software subsystems manage operational modes through a state machine, tracking standby, nominal operations, safe mode, or maintenance configuration. The ICD and requirements documents specify state transitions, the commands that cause them, and packet outputs indicating each change.
For lean teams, state-machine coverage is another high-value target. A typical subsystem has a manageable number of states, with four to eight operational modes being common. Transitions are more numerous but finite. Testing every reachable transition from each state with valid and invalid triggers gives meaningful mode-logic coverage without exhaustively tracing the entire software.
State-machine tests need no hardware. A software driver can send synthetic command packets and inspect TM output for the expected mode-indicator fields. It must use the same packet encoding and decoding logic as the flight software, which the generated code supplies.
Defer These
With limited hours, defer exhaustive testing of internal algorithmic modules already well-tested by their library or component sources. A subsystem using an off-the-shelf CCSDS packet-framing library need not retest that framing logic exhaustively. Spend verification effort on the library-to-subsystem integration, especially where subsystem field values enter library functions. These boundary points carry the greatest error risk.
Performance and throughput tests also matter, but can wait for hardware. An encoder's correctness does not depend on running in 1 microsecond rather than 10 microseconds. Timing behavior must be confirmed on the target processor, so run that test when the target is available.
Tool Costs Are Manageable
Lean teams may lack commercial tools for test management and coverage measurement. Such tools help, but meaningful V&V does not require them. Open-source options can measure coverage: gcov for C and Python's built-in coverage module for Python. A spreadsheet can manage cases when the RTM maps ICD fields to tests. The key question is whether each ICD interface requirement has a test, with results recorded and traceable to that requirement.
Spacebackend's free tier provides up to 500 generated code lines monthly, enough for a modest packet library and its test stubs. Teams comparing generated stubs with manual writing can validate the approach before choosing a paid tier.
What Lean Testing Can Cover
Generated stubs and focused verification hours can cover ICD interface requirements, exercise critical state-machine transitions, and find boundary-condition defects. They do not provide complete structural coverage of the flight software codebase. They also do not replace a formal launch readiness review or an independent review of test evidence by someone with suitable technical expertise who did not write the code. At a reputable program review gate, reviewers will ask about coverage. A team with a verified, traceable ICD-aligned test suite can answer more defensibly than one that tested informally and retained no artifacts.
