Testing, summarized to one sentence: When you are testing your software, your most colossal failures are your most colossal victories, but only because you found them before you went-live.
A few years back, I was on a project where one of the testers found a gigantic show-stopper at the 11th hour. The boss was beside himself, “how could this happen? How could we have missed this one?!” I had to reassure him that, in fact, we had not missed it. We just caught it late. Even though it killed our release, imagine what would have happened if we had not caught it at all!
Although it was a big failure for the dev team, it was a gigantic win for the testing team. Once the boss got his head around that concept, he was able to boldly address the (money) people and declare that blowing this release was the best thing that happened all week and waved a red “win” flag instead of a green one.
This is a tough one for many IT folks to get their heads around: testing is a hedge-fund investment. When you lose, you still win (just in a different way).
If you count on your developers or users to do your testing, you are living without insurance. All your eggs are in one basket or, if you have your users do the testing, then there is no basket at all and you have your eggs lined up on your arm or in a wet-paper towel or something.
There is only one way you lose with testing: a bug slips past your developers and your testers. At least, with that scenario, you can say that you put-forth a reasonable effort. You have a base that you can improve upon. Namely, you can review your tests and process and find the hole in the testing process and plug it. That kind of bug will never beat you again. That is a much better scenario.
Learning from your mistakes is the second-best outcome from anything you do. Of course, it is always best to learn from somebody else’s mistakes and not make them yourself. Which is why you should use organized, professional software testing.