Another perspective: What value does a multinational megacorp place on tests? (In the typical case, probably not Yahoo.) Seasoned MBAs debating whether DAOMock is *really* a mock or just a stub?!! Due diligence is hard enough for grown-up matters like customers and revenues and viral long-tail stickiness. You and I know that a high-quality test suite is indeed a valuable asset, but in reality, the only software that counts in an acquisition is that which lives in end-user-land.

These chances (again, my experience) go all the way to something like 90/10 in favour of tests reducing time spent developing after the first round of iterations, but then, if we’re talking economics, it’s just a higher risk - not a certainty - that you’ll get screwed by lacking tests. If you bet on not writing tests and still manage to write good quality code and sustain productivity, all else being equal, you spend less for the same business value (although you get less technical value, because, as you point out, a nice automatically tested codebase is easier to refactor in the large scale).

When you create unit tests (for automated testing), you spend LESS time developing. The unit test quite often contains the bulk of the code that will be your implementation code anyway, and also serves as self documentation as to the code usage, and so makes you more productive.

Unit testing also promotes large scale refactoring. With manual only testing if you find a bug and fix it, you need to begin your testing process over - how do you know that your bu fix has not broken something else? with automated unit tests, you know this immediately.

Not using unit tests MAY be cheaper if you simply don’t care about testing - you can just let the users do it, and I don’t know - leave a “beta” logo on the page until you feel that they can’t find any bugs

However, in the long run, not using unit and automated testing creates developers who are scared of their own code, and unwilling to refactor because they are scared of breaking something. This introduces more and more code smells until you end up with something that makes grown men weep.

I think you’ve missed a row in your table above. I’d see things more like:

Scenario A B
Development 10 10
Manual Testing 2 8
Automated tests 8 0
Maintenance 2 10

In short, just because the Flickr guys don’t do automated testing doesn’t mean they do no testing at all (I hope). Whether you’re automating it or no, you literally cannot help perform some testing on code under development. Maybe this testing is just a case of “I’ll fire up the app and make sure I can run the stuff I just added” … that’s still testing.

Where automated testing does introduce savings (after the initial cost) is the rapid re-running of these tests whenever needed to identify regression issues.

Where I think Carlos made a great point, but still wonder if PHP programmers care about testing

In flickr-style companies (smart people, low resources, not that far from old days dotcoms except for they want to profit, not to IPO) I generally see this QA stuff being created after the company achieves some profit to hire more people. Somtimes it works, but in most occasions it just fails I think.

So what about the cost of injecting a QA process based on automated testing in company B after, say, the first version?