Why do we need Automation Testing ?
There are several reasons why we should automate our testing process. Automation testing is desired because it:
- Saves Time and Money: Software testing is a repetitive process and is often repeated once the source code changes or prior to a new built release. Manually testing the whole process for several times means a monotonous task for the testers and it may result to an ineffective and inefficient testing process. It needs a lot of human effort, and time. On the other hand, once created, an automated test can be run over and over again with no or a little maintenance at no additional cost. It is much faster than the manual process and hence reduces a lot of time. A time savings that translates directly into cost savings.
- Increases Test Coverage : Automated software testing can increase the depth and scope of tests to help improve software quality. It can test a bunch of test cases against a wide input range by looping the particular process for n-number of times which would have been impossible had we followed manual testing process.
- Improves Accuracy : Even the most experienced and conscientious testers will make mistakes during monotonous manual testing and may give a miss to one or more test cases at any point of time. Automated test performs the same steps every time they are executed, never miss a single step and never forget to record detailed results.
- Does what manual testing can not do: Automated test is able to simulate a large number of virtual end users to a system to test how the system reacts under stressed conditions . Following manual process to perform load testing and stress testing is simply impossible.
What is Automation Testing ?
As the name specifies, Automation Testing is using a software to control the execution of test cases and report the result of the test execution. In other words it can be stated as automating a manual testing process with the help of an automation tool to reduce human effort, time and cost spent to test an application.
When to Automate ?
So when do we automate our test? There may be a tons of question regarding this but with a common theme and that is “What is the return on investment on automating this test?”.
We have many aspects to look at and many queries to answer to decide whether an AUT(Application Under Test) is a suitable candidate for automation or not. Some of them are listed below:
- Load Testing : In case of load testing it is just unimaginable to follow a manual testing process because arranging a thousands of end users to put a heavy load to the system and test the system response is just impossible. In this case we are bound to automate our test as with the help of load testing tools, we can simulate as many numbers of virtual users we want and perform load testing.
- Scope of Automation : Scope of automation refers to what is the percentage of the total test cases for an application can be automated. In general, if 60% of the test cases can be automated then the AUT is a suitable candidate for automation. There will be some part that can not be automated due to many reasons like need of frequent manual intervention etc. If for a particular application, most of the parts need manual intervention to test the functionality then obviously it is not a suitable candidate for automation and the scope is very less.
- Script Death : Script death is the time when the automated test is no more valid and can not be used to test the functionalists. When the scope of automation for an application is large and almost all test scenarios can be automated, for some application it may happen that with the release of a new version of that application the automated test is no more valid to test the new version and an effort to re script the whole automated test is needed. In this case we may say that Script death occurs very soon. So this kind of application are not suitable to be automated.
- Feasibility : Feasibility of test automation with respect to time and money is also considerable. For instance, we have created an automation script. Now we have queries like if this script will save me 5 minute’s worth of time, and it will take me 100 minutes to write, will the script run 20 times to break even for my invested time? Will it run longer and actually save me testing time in the future.
These are some generic practices that we follow across all application and automation tools.
Identifying areas to be automated within the application.
One of the classical mistakes of the test automation team is: ‘NOT choosing right test cases for automation’. We need to identify areas in the application which are prone to issues if something is changed within the code and areas used extensively by end users. We need to leave out areas which are used least or do automation at a basic level for these modules rather than spending more time and resources.
Co-ordination with Development with changes
Automation tools use properties to identify and locate controls. For example , while searching for a button , we may be using the label to locate the object .If there are changes made to labels , Developers should inform the QA about these changes so as to make necessary updates to the script. Test Automation can team up with the Developers to provide unique names so as to assist both script and automation engineer to identify the controls.
Setting up the Best Team
This is also one of the important factors that holds the key for achieving a successful automation or a failure. We need to pick a balanced set of people having skills suited for the test automation and having in depth knowledge of the product.
Automation Plan
This is probably the back bone of the total automation effort. We need to have reasonable expectations from our automation nothing like that it would replace the Manual testing. Few possible things we can imagine are
- This would speed up the testing and hence faster and cleaner delivery .
- Improved Test coverage by covering all areas of the application even those which would ideally be skipped in manual testing for lack of time.
- Reliable , consistent testing of the application.
- Test case coverage of the application which would help us narrowing down on areas best suited for automation
We can focus on automating Regression testing – tests run at every build. We need to formulate the automation plan as such it identifies the initial set of tests we can automate and gives us valuable feedback for future tests.
Bottom line is ,Taking the manual test cases as an input, identifying the homogeneous test cases that will fit in one automation script, and preparing the automation test cases for the bunch of manual test cases.
Modularity
Dividing the whole automation test cases into several logical units and creating different action for each unit. Then we can create a batch clubbing the individual modules and run it to achieve an End-to_End like scenario.
Re-usability
Re usability here refers to Code re usability and Object re usability. Code re usability can be achieved by creating function library consisting of many functions which can be called any number of time. Object re usability means using the same object for different actions/tests. This can be achieved by using Shared Object Repository.
Measuring the Automation Progress
We need to make sure Automation is a full time,dedicated effort. Test automation implementation requires dedication and focus to ensure success. In this instance, it is better to not implement test automation than to allocate ad hoc time for experimentation. We need to come up with some metrics to gauge the progress of the automation effort . Few things can be like :
- Is the testing a particular module faster in automation compared to manual.
- We are able to test more features in the same time and reporting any breaks/issues with latest code to development team.
Prerequisite Document
This document describes what are the things need to be taken care of prior to run an automation script and has description about each action in the test. This includes data inputs needed during testing which are generally provided through an external excel sheet or data table, running automation tool settings script etc. We can make this document more descriptive by including what are the test cases covered in a particular action so that looking at them we can have a high level idea about the test coverage through the script.
Written By: Sonali Ghosh, QA Engineer, Mindfire Solutions
