Best Practices of Test Automation
To get maximum ROI out of automation, here are some best practices to be followed:
1. Know what to & what not to Automate
What to Automate?
· Test Cases which are important to be repeated in every release cycle.
· Test Cases which are time consuming & tedious to execute manually because chances of human errors are high in this case.
· Test Cases which are High Risk or Business Critical.
· Test Cases which are easy to automate makes it cost effective
What Not to Automate?
· Test Cases which are not easy to automate. Effort will out weight the returns in this case.
· Infrequently executed test cases.
· Frequent requirement changing test cases
· Test cases where human intervention is a must.
· Low priority test cases
2. Keep your Tests Dry
Approach the design, implementation, and maintenance of your test suites with the same engineering and craftsman mindset you approach the design, implementation, and maintenance of your system’s data access layer, business logic layer, etc. If you’re not already familiar with the SOLID principles authored by “Uncle Bob” Martin, then take some time to read up on them. These principles are targeted to developers writing systems; however, the same principles apply directly to testers writing automation suites – if perhaps not quite to the same degree.
While I try to pay attention to all the SOLID principles in my test harnesses, I find that the DRY principle (Don’t Repeat Yourself) is especially critical for keeping my sanity as I build and maintain test suites. If you’re going to pick up one new thing about software engineering or craftsmanship, learn to love DRY.
DRY means avoid duplicating things in your test suite. One example of duplication in a test suite include having your element locators (IDs, CSS class names, XPath definitions, etc.) defined in more than one spot. Another example would be having every test perform the same steps to log on to a system.
This sort of duplication doesn’t seem like an issue when you have 20 or 50 tests, but wait until your test suite grows to hundreds or thousands of tests – and then go try to fix failing tests when (not if!) your UI or system flow changes. Duplication of this sort crushes the maintainability of your test suite over time – you spend more time fixing broken tests than you do delivering great value elsewhere.
3. Measure your ROI:
Success of automation cannot be determined by only comparing the manual v/s automation effort, but also by capturing the following metrics:
· Time required for executing automation testing for each and every release cycle
· Reduction in Time taken per release (Productivity improvement)
· Customer satisfaction Index & %age of defects found
It is good to follow a detailed process to achieve best results from automation. At a high level automation has following important stages:
A) Planning, Design & Development
B) Execution & Reporting
The above guidelines if observed can greatly help in making your automation successful.
Did you Know? If you have chosen CloudQA to handle all your web-testing, you don’t need to plan anything about scripting as it is code less and keep your tests DRY, making it easier to maintain your tests. CloudQA magically runs all your test cases exactly the way you have recorded. Obviously, it saves you lots of money as well as resource time. You get more bandwidth to focus on important things to develop your product to beat the competition!!!
To know more about this amazing web-testing tool, visit www.CloudQA.io