We had a history of development where there were developers, and like all people, developers made mistakes. So, we hired testers to check their work. As test automation as come along, now we get special “software developers in test” to write the tests.

That’s a step in the right direction, but I still think it’s not right. We should get rid of testers and SDETs and have developers write the tests. Instead of having 1x dev and 1x tester have 2x dev/test. The output of features will be the same, but the quality will be better.

At Cheezburger, devs write all the tests. We have one “user tester” who does all his testing through the browser. His job is to simply act like a user and ensure the site is working right. We also integrate him very early on in the design process, so that he can eliminate “bugs” before any code is written by simply saying, “guys, to a user, that won’t make any sense”.

In regard to your 2nd and 3rd questions:

1. Doing tests “well” means being thorough. You have to think of every case, even the ones that are unlikely.
2. Yes, the web is difficult. We use Selenium with some success, and there’s an neat startup in Seattle called Browsera that’s doing some really cool stuff with the visual validation of pages. We tried them out in early alpha, and it proved helpful.

What are some practices that you find to do automation “well” in your particular domain?

As the world of the web seems particularly brittle and you have some particularly unique challenges with multiple components.