Thursday, December 10, 2009

Candidates which are suitable for Automation

It has been always noticed that people are confused about what to automate and when to automate. The main reason that I feel is the inexperience with automation that puts people into such a dilemma. Proper understanding of automation concepts would help one resolve this question. The answer lies in the same old definition of automation. Why do we require automation? In order to reduce manual errors in repetitive and iterative tasks. It proves to be the answer to the question of what needs to be automated as well. Any task that needs to be executed repetitively and iteratively across releases need to be automated.

The reason behind this is the fact that complex iterative tasks become really a factor that could lead to human errors. But such errors are really not acceptable while you are in production releases. The release dates always become a bound on the tester as a matter of time that he can spend on a module or the complete test. This induces the tendency of creating errors in the process. Let me take the example of testing a desktop application. If the tester is manually executing the test cases that he had prepared before the first round of testing, by around the 15th round of testing, the tester would be confident enough about the test cases and steps. Once he faces frequent releases again and again, he might be in a position where some modules would be skipped from testing due to the information that the feature was working in the previous releases, and the chance of breaking is none. But this assumption should not be correct all the times. Believe in me, I have seen functionality breaking after somewhere after 18-20 releases have been passed. Think of the case if it was an automated script that was testing the application. It would not mind if it was the 10th or 100th release. It will still execute the same steps again and again, whenever it is played. This avoids the chance of any issues being propagated through the release due to human errors.

This does not cover everything. Executing Test cases is only one part. There are more aspects of Automation that could be utilized. Whatever process is very time consuming and tedious due to its complexity, is always a good candidate for automation. Consider the example of a product solution, where there are around 25 servers and applications that need to be installed for installing the product. If it takes 4 hours to install a server and bring it live with all applications, then the total effort required would be 100 man hours which is approximately 13 working man days that gets utilized in the process. This certainly is a candidate for automation, and should be automated with immediate effect. A simple automation framework could be utilized, which could perform installation on different server machines, controlled by a single central machine and with little human intervention. This process could be achieved in the count of some hours only. This could save a lot much of effort, and prove worthy enough for the company as well.

So the automation task is regulated by some factors like
  • Repetition of  Testing tasks
  • Iterations that need to be executed
  • Complexity of tasks to be performed
  • Time consumption by the various tasks involved, and so on
At any time, test automation should be made into use, so that the manual effort could be focussed more into finding bugs that exist in the application which are not revealed through test cases.

1 comment: