I’ve been working with teams with testers and with teams completely without them. My experience is that there are always bugs and about the same amount of them.

I’ve been working with teams with testers and with teams completely without them. My experience is that there are always bugs and about the same amount of them. It seems like it never matters how much effort you put in. I think it’s had to be about ownership and who is going to have to wake up in the morning to fix things. One thing that I believe that’s also left out here is that Test-driven developed code looks different than code that isn’t. All the TDD code is per definition testable but other code isn’t always testable. (Mind you, I say code here and not programs.) I also feel like there’s a missing point in the article, which is how easy something is to test. If it’s not easy to test something or setup a test for it it will probably never happen. I think you should write systems to be easily testable since then people will do actual testing. And if you don’t test that continuously (that it is testable) you will end up in a system that is eventually harder to test. Automated tests will not happen for something that isn’t easy to test and automated tests are kind of a way to acknowledge that “well, at least this works”.