I know it was a throwaway, but be careful about the "untested code never works" comment. It plays into the fallacy that if it works, it's adequately tested.<p>You talk a lot about testing for specified requirements, but not so much about looking for undesired behavior outside the requirements. That's where the fallacy bites you. It's especially pernicious when you start to firm up a working prototype or are inheriting a legacy production release with a history of good behavior, but which is about to change execution context in some way. Changing the context means hitting unexplored territory and there be dragons.<p>Of course, you're a professional tester (as am I), and I know this is obvious for you. But for the average PHB or engineer-driven organization trying to prioritize, it's important to be pretty clear about this:<p>Untested code works great in the 95% case--this is one of the big reasons QA has a credibility problem sometimes, because they're spending $$$ to confirm it already works. It's the 5% case you need to worry about. It can kill your product or, in your case, the patient.