Test Automation means different things to different people in different contexts. But a most common definition states that, “Test automation is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions”. Few weeks back I met a team of automation experts to get their input on when to automate and when to manually test. The general rule is always to use common sense. If you require a test to run only once or twice or the test is really expensive for automation, consider it for manual testing, else for automation. “An Intelligent Answer, isn’t it?” But then again, what good is saying “use common sense” when you need to come up with deterministic set of guidelines on how and when to automate?

Test automation raises our hopes yet often frustrates and disappoints us. Although automation promises to deliver us from a tough situation, implementing automated tests can create as many
problems as it solves. The key is to follow the rules of software development when automating testing. Many consider Automation to be an easy way out where you use an Automation tool to record and play back the test cases and expect it to deliver the desired output. Automation is a niche area where considerable thought has to be given to the goals or else automation can become a liability in place of an asset.