Test normal work and the path back from failure

A useful test specifies its starting state, inputs, action and observable outcome. Component tests can isolate a calculation; integrated tests examine interfaces and timing with other parts of the system. Both matter because locally correct software can still interact incorrectly with hardware or another subsystem.

NASA’s software testing guidance includes requirements-based testing, representative platforms and regression checks. The point is not simply to accumulate a large number of passing tests. The evidence must address the behavior the mission requires, including relevant limits and unexpected conditions.

For a fictional instrument controller, normal operation reads a valid sensor and produces a bounded output. A fault test might provide a stale reading and check that the defined fallback occurs. Another might interrupt power during a state update and inspect whether restart preserves a consistent state.

These are conceptual test scenarios, not instructions for operating real flight hardware. Each test should state what the simulator or testbed actually represents. Injecting a software error in a model does not necessarily reproduce the physical timing or electrical effects of every hardware fault.

After a change, regression testing — open definition checks that relevant previously working behavior still meets its requirements. A repair can affect shared interfaces, resource use or timing. The exact software and configuration used in the tests must be identified so the results apply to the intended release.

A fictional patch corrects a sensor conversion but increases processing time beyond a control deadline. It fixes one problem while introducing another required behavior failure. Evaluate the resulting system, including recovery and update procedures, rather than judging the patch only by the one example it was written to repair.