How can you get your test automation project off on the right foot? I've been asked this question many times. It has prompted me to review the test automation projects in which I've been involved and identify the factors most associated with success.
Commitment Is Essential
The team needs to see test automation as necessary and critical. The whole team must be committed to test automation.
I saw the benefit of this kind of commitment on one project where the test plans and project plans assumed from day one that a means for automatically executing tests would be available. When the first person with responsibility for test automation admitted defeat, it was given to another. And then to another when the second person couldn't get it to work. This third team member was able to get additional assistance and finally got the automation to work. Because each participant knew the team was counting on the automation, the project stayed alive with increasing urgency and effort.
More common in my experience are teams that see test automation as something nice, as something to put some effort into, but not to bet on. They make sure they have fallback plans for manual testing in case the automation doesn't work out. Invariably these automation projects don't get the attention and assistance they deserve.
Nevertheless, I have seen some smaller successes arise from such circumstances. In each case, it was because of efforts by outstanding individuals who demonstrated personal commitment, technical accomplishment, and loyalty to the team. The loyalty of these individuals meant that they stayed on the team for years, always prepared to step in and help with the test automation. It was their baby and they weren't going to let it be abandoned.
Ultimately, commitment is key, whether from the team or from individuals. Without it, automation efforts—however laudable—invariably are abandoned.
Work Together as a Team
A second key I've observed that contributes to test automation success is effective partnership between testers and developers.
From my experience, testers who head test automation efforts without significant involvement from their developers are prone to make several errors. They fail to appreciate how their test automation project needs to be planned just like other software development projects. They underestimate their need to understand the test automation technology they're using. And they aren't in a position to simplify the test automation by adding testability hooks into the software under test.
On the other hand, developers heading up test automation efforts don't fall into these traps, but have been prone to providing automation that doesn't meet the real needs of testing. I've seen them generalize from experiences testing their own code, not appreciating the importance of finding errors that they didn't make. And I've seen them develop whiz-bang technology that looks cool, but doesn't really help get the testing done, because they don't understand the real testing problems.
The best efforts avoid these various traps by having testers and developers jointly charter the test automation effort. This is not just a matter of skill. You actually need to have members of the development team involved. Only they are aware of ways that they can make the software easier to test and are in a position to make it happen. And key tester involvement ensures that the results address bona fide testing needs. This kind of teamwork is very effective.
Less effective, but still capable of success, is having developers independent from the product development team assist a testing team with test automation. Some effort must be made to work with the product development team on testability issues, but in these cases full participation from the development team was not required for success.