For all but truly trivial problems, it is impossible to test every possible situation that the program might encounter. Users can imagine far worse data-driven scenarios than any test engineer or programmer can think of; we all hope the hardware is always working, but we never really seem to know if it is.

In a very important way, this is all about achieving software correctness. Attaining as great a level of software quality as money, time, effort and risk management dictate we can and should achieve. Theres a whole new set of buzzwords associated with this, so you might start adding them to your software risk mitigation glossaries!

Discussion: This week, let's talk about how we design to be fail-safe. Also look at how we lay out a verification and validation strategy that can affordably gain us enough reassurance to release a software system to its end users. That V&V (verification and validation) strategy includes a mix of the main techniques of software quality assurance: inspection, analysis, test, and simulation.

Since you cannot test everything, or test it exhaustively, how do you go about choosing what mix of V&V strategies to use, or how much of them to use to be able to feel ready to hand the software over to the end users with a clean conscience?