Let's look at it a different way and start with the assumption that in all cases we're delivering reliable software, it's just a question of how we get there.

Let's look at it a different way and start with the assumption that in all cases we're delivering reliable software, it's just a question of how we get there. The simplest way of doing this is to write code with good practices then do a load of manual system testing to find bugs (system testing including user acceptance testing in this example). This is basically what most people were doing 20 years ago. This can work, but doing the system testing is time consuming and so expensive and so makes making changes expensive. Instead you automate some or all of your system testing. This makes them cheaper, but these tests are expensive to maintain and still time consuming to run. If the test fails you don't have that much information about the problem. To complement (or maybe replace) your automated system testing, you add tests for smaller and smaller chunks of software, allowing for tighter feedback loops and more precise diagnosis (there are also some negative tradeoffs). Applied well, this allows you to write features more quickly, refactor more confidently and generally develop more efficiently. Basically, it's not so much about catching bugs as it is about getting to your desired level of reliability in the most cost and time efficient way.