[waterlion]

What happens when your customers' data is lost or corrupted because of a bug you could have caught?

[a3voices]

Data redundancy in multiple locations and good logging can fix that problem better that tests, I think. Most bugs can be found anyways during development without coded tests.

[waterlion]

For a very narrow range of software, I suppose. Not for software that has side-effects and actually does stuff in the real world.

What about software that sends emails to people, or places orders, performs billable work, or gives people directions, or supplies them with data that they then carry forward and use in decisions or in other systems?

And are you proposing that instead of writing tests you write a play-back-able-log system that can roll back state and re-apply transformations if a given component did incorrect things?

I think sensible testing is the way forward, where sensible is appropriate to the type of application, language and requirements. 100% coverage is suitable for industrial code and 1% coverage is appropriate for toy projects. But no tests at all seems foolhardy.

[twerquie]

That's not going to save you from failing to capture key records, or capturing them incorrectly.

You do have a point about manual testing being just as effective as automated testing, just a lot more time consuming.

[angersock]

If your data transformations are bugged, you've merely succeeded in duplicating redundantly the wrong answer--backups won't save you.

[RougeFemme]

Not sure what you mean by "coded" tests, but I agree that most bugs can be found during development - unfortunately, my experience is that that's rarely the case. But if your development team finds most bugs during development, my hat's off to you.