I’d like to add that I didn’t mean that developers shouldn’t do any testing, just that they should avoid testing their own work and perhaps ask other developers to test it. After all some things would be very hard to test without programming background for example.

In that sense I would also consider pair programming and code reviews to be an important part of failing fast. Unfortunately both of them are often neglected and considered to be waste of time. [sigh]

Regs,
AC

You really nailed it with this one:
“I guess it’s just human nature to attempt to hide crap under the carpet.”

first of all, you are absolutely right about acceptance testing being a manual process. What I meant to say was that you can automate the acceptance tests. I wrote another post to clarify this, see the pingback comment below.

You are also right in that testing is harder than one might think, and that good testers are hard to find. To me, this is just another reason to automate as much as possible.

I also agree that testing should be done by others than the developers, but - and this is important - this doesn’t mean that developers shouldn’t test at all. I’ve seen too much of the “let the testers do the testing” mentality, and it’s always been disastrous. As I said, rapid feedback is the key to success.

I’d be curious to know how you automate (user) acceptance testing. I can understand automated integration and system testing, but I consider acceptance testing as something usually done by testers or real users.

And in my experience testing is usually much harder than one might think and I consider finding good testers as hard as (if not harder than) finding good developers. But maybe that’s just me.

An important thing to keep in mind when talking about automated testing (beyond unit testing) is that testing should always be done by someone else than the person responsible for the implementation. It’s hard to see your own mistakes. Basic stuff yes, but often neglected.

Regs,
AC