Automation can never hurt, but it is never a replacement for real human testing. And you can easily get into situations that are not cleanly testable -- scalability of large distributed apps, machine dependancy, kernel dependancy, timing issues only seen in real world apps, whitebox mentality of end users, firmware or driver involvement in some cases, etc, can result in test automation that requires a huge farm of available hardware. It depends on what kind of code you write, I guess, but in my case (at least), I see a lot of code (not just Perl) that does not fit cleanly into automated test frameworks. Moral of the story -- know when to use automated testing, as well as when automated testing is not the only solution. Obviously having an organization that doesn't agree to spend cycles in Q/A is a bad one in need of fixing!