Ok, Myth #3: An automated test must find bugs to be useful.
So think of test automation like that insurance policy.
Just as insurance gives you peace of mind, so to does test automation.
Let me give you another example.
My team has been in a coding milestone for 10 weeks now. Monday, we start a stabilization period. When we started the coding milestone, all our automated testing was passing 100%. Our smoke tests, for the most part, have been at 100% throughout the 10 weeks. Up until about 4 weeks ago, our set of daily automated tests were passing at 100% . But we took a partner drop, and sure enough, we had 2 failures in that larger set right after that. Next week, another pickup, and now 4 failures, the next week 7, and the next week 9. And we had fixed many of the previous weeks failures and bugs filed against our partner, but we couldn't get ahead of the incoming breaking changes.
So here I am, using my test automation finding bugs as an example of why a test's entire purpose in life is not necessarily finding bugs. Huh? Adam, didn't you say that the real value lies in the test validating that defects haven't been introduce? Well, what useful data can you derive from the tests passing consistently?
There's really alot of valuable data from a well designed test automation system that has well designed tests that "don't find bugs" because they are passing regularly.
One more time:
Test's don't have to "find bugs" to be useful. Test automation's real value lies in validating that defects have not been introduced in previously working code. Tests that pass provide meaningful data about the state of the codebase under development and the development process.