Ok, let me get up on my soapbox

If testing can't prove a product what else can ?

Nothing can "prove" a product How much testing do you think the first Mars lander went through and the software still failed.
If you, just rudimentally, analyze all paths a program can take, you will soon see that "complete" testing is impossible. Just try to figure an interrupt happening at any point in the main or lower priority interrupts.
Thus: succesful testing does not prove the abscence of bugs, it only proves the abscence of known bugs

I know that, in some other threads, I have come under attack for promoting "defensive coding" but that, in my opinion, is the only way to go.

While I appreciate your basic emphasis on "exhaustive field trials" there is also this case of " adequate for the purpose" and I am not talking of mission critical or medical applications.
While I definitely agree that "exhaustive field trials" is required before releasing a product (why else would we have the name "beta release") I do absolutely not want to put any reliance on that. Testing at all levels is required (of course, have to test and debug what is made here) but that is no excuse not to code for no bugs.

The point I am trying to make is that too much software is put together with the attitude "if something is wrong, the testing will find it". If you can not code with confidence that the code will work immediately (all of us are repeatedly proven wrong there) the result will suffer greatly.

What is "defensive coding", some (but not all) points:
1) If there is a mundane road and timing etc allow, take it.
2) If an ISR can not be kept short, retink the process.
3) Do not worry how "elegant" your code is, mundane is beautiful.
4) Do not worry about making your code work, worry about it being maintainable. Maintainable code that does not work can be fixed, non-maintainable code that "work" fall apart the first time a change is required.
5) ALWAYS remember to mark the "traps".l e.g. if you have something dependent on the oscillator frequency, enclose it with IFs, then if the frequency is changed, no place is missed.

As you will see, you can ignore all the above and still make a product that can pass testing, but some day something will happen such as an interrupt ocurring at a specific place and BOOM.

Thus reliability and maintainability must be coded in, they can not be tested in.

Erik