Top 10 Test Automation Strategies and Best Practices

This is the last article in the test automation series. This article summarizes the best practices and strategies for doing test automation.

Although our previous articles do mention best practices (and some of them may be repeated here), I strongly felt to list down the few, but most important best practices of automation here in one article for reference.

These strategies are taken from my own experience plus from the literature of testing gurus like Michael Bolton, James Bach, and Cem Kaner. These practices should be followed in every automation project.

10 Best Test Automation Strategies and Practices

Here we go..

#1. Hire a Dedicated Automation Engineer or Team

This is a basic thing to do. Don’t ask your manual testers to indulge in test automation. If you do want them to do test automation, then free them from manual testing work. Test automation is a full-time job. For this, you need dedicated resources.

I recommend building a test automation team consisting of at least one automation architect. You can hire multiple automation engineers to work under the guidance of the test automation architect. The number of automation engineers depends on the number and size of your products.

#2. An automation tool is important, but it is not the solution to everything

We talked about tool selection. But selecting the right tool is just the beginning. Some managers have the misconception that if they select the right tool, they can easily automate anything. Beware, automation tools do not give you everything. They make the process easier. But you need skilled resources to complete the process.

Often automation tools are buggy and they stuck in identifying complex objects on the application. The resources you hire, if they are skilled, come up with a workaround which takes the process forward. Otherwise, if you don’t hire good resources, Tool alone cannot guarantee successful automation.

#3. Select the automation tool which is familiar to your resources

If your resources are familiar with C# and your application to be tested is also developed in C#, then there is no point selecting the tool which does not offer C# to write scripts.

Language learning is a time taking process. Avoid this learning curve by buying a tool which offers a minimal learning curve.

#4. Know the application being tested

The tool selection depends heavily on the technologies used in your product. Know your product inside out before starting the automation.

If it is a web application, know the browsers it will support. Know the technologies being used in it. If it is a desktop application, know which language is built upon. What third-party controls are being used in the application. This will help you make the tool selection and future automation easier.

#5. Good Automation means good manual test case

Nicely written strong manual test cases save us from automating those test cases which are easy to automate but weak in finding defects.

Here is the quote from the book Lessons Learned in Software Testing:

“Automating without good test design may result in a lot of activity, but little value.”

It is always advisable to first write the test case in manual form. Identify all prerequisites and test data. Write steps in a clear manner and write expected results in front of each step. The objective of one test case should be clear and it should be less dependent on the other test cases. Automation engineers should run this test case manually at least once to clearly decide what objects need to be identified and what will be the flow of navigation. Ask questions with manual testers.

This activity sometimes helps to identify bugs even before the automation script is written. Experts say that the majority of bugs is identified in the test automation development phase rather than in the actual execution phase.

#6. Identify opportunities with automation

If you are handed over with a manual test case to automate, don’t just automate that test case as it is. Instead, find further opportunities in your automation, to expand the scope of this test case.

For example, if the manual test case requirement is you have to login to a web page. You can expand this test case by making it data-driven. List all the possible scenarios of login like invalid password, empty password, invalid username, invalid email, blank username, remember me checked, not checked, etc. List the possible scenarios along with their expected result in an excel file and put this excel file as a data source to your test case. Now this one manual test case, after being automated, can test all the possible scenarios in one go.

Always look for opportunities that can be done with automation, but difficult to do manually. Such as Load Testing scenarios, Performance Benchmarks, Same Tests under different environments with different configurations, Memory Leaks, High Precision Tests etc. These all are difficult scenarios for manual testers.

#7. You cannot automate everything

Automation means running fewer tests more often. You have to start small by attacking your smoke tests first. Then cover your build acceptance tests. Then move onto your frequently performed tests, then move onto your time taking tests. But make sure every test you automate, it saves time for a manual tester to focus on more important things.

Automation is not here to replace manual testers. Nor it can. It is here to take the repeated work away from manual testers so that they can use their full focus and strength in finding new testing scenarios and bugs. (Read my article Misconceptions of test automation)

Automate a few tests that are valuable and time savers or difficult to do for manual testers. If you did that, the task of automation is done.

#8. Avoid GUI Automation when there is an alternate present

GUI automation is always tougher than other types of automated tests. So if there is a situation when you can achieve your target by not automating the GUI, but by some other methods like command line inputs, then the best strategy is to avoid GUI automation.

For example, you want to test the installation of the application. The objective is to check whether the application installed or not in a particular environment. One approach is to start the installation and click on the “Next” button multiple times through your automation tool. It can be tricky, time-consuming and it is subject to maintenance if UI changes. The other approach is to initiate the application installation with a batch file giving silent arguments. The application will silently install showing no GUI. The objective will be achieved in less time and in a more reliable manner.

#9. Use Automation for other useful purposes as well

Automation is such a fantastic thing. You can achieve such things from it that you don’t normally think about. Automation is not just about programming a manual test case. Instead, you can use automation to facilitate different operations in your organization.

For example, you can use automation to create master data and setup configurations automatically for manual testers. So that they can start their testing as early as possible.

I can give one example from my own company. We wanted to switch from our test case management tool. We were using “Test Director” (now HP ALM) and wanted to switch to TFS (Team Foundation Server). We had around 4000 manual Test Cases and Bugs in Test Director. Transferring them manually to TFS could take about a month. So my manager asked me to try some automation.

I dig those tools and found out that Test Director is using SQL server as its repository. For TFS, I found out a tool that can read test cases and bugs from an excel file, if they are written in a particular format, and can insert them in TFS. The Rest of the story is simple. I wrote an SQL query to fetch all test cases and bugs and exported them in an Excel File in the specific format. I then used that tool which reads all test cases and bugs from excel file and inserted them in TFS. The whole process took only 3 hours. My manager was very happy. I hope you get my point too.

#10. Automation is software development

If you develop quality software, it needs best practices. It needs code reviews to write quality code. It needs a framework or design pattern to be followed. It needs constant maintenance.

Automation is basically software development. So all best practices you follow when you develop software should be followed in doing automation. Automation Framework should be there. Code Reviews should be done. Bugs of automation should be reported in the bug repository. Source Code of automation should be placed under source control, etc. The more you treat it like software development, the more successful automation will be.

Conclusion

This sums up the article as well as the series of test automation. I learned many things while writing these tutorials and I hope you learn as well by reading. Test automation is an interesting and rewarding career. Doing it correctly is not only beneficial for you but for the organization as well.

Every day while working on test automation and its techniques, I find new and interesting challenges to solve. This series was an attempt to highlight what could come across on a journey of test automation. I hope I delivered it right and in a simple manner.

As always, I wait for your comments and suggestions. Feel free to write your feedback in the comments section. I will be happy to hear from you and help you if needed. Thanks for reading.

PREV Tutorial #6