10 Best Practices and Strategies for Test Automation

This is the last article in the test automation series. This article summarizes the best practices and strategies of 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 Practices and Strategies for Test Automation

Best Practices for Test Automation

#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 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 of everything

We talked about tool selection. But selecting the right tool is just the beginning. Some managers have the misconception that if they select a 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 workaround which takes the process forward. Otherwise, if you don’t hire good resources, Tool alone cannot guarantee the 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 time taking process. Avoid this learning curve by buying a tool which offers 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 saves 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 majority of bugs is identified in the test automation development phase rather than in 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 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 application installed or not in a particular environment. One approach is to start the installation and click on “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 a 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 a software should be followed in doing automation. Automation Framework should be there. Code Reviews should be done. Bugs of automation should be reported in bug repository. Source Code of automation should be placed under a 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 you and help you if needed. Thanks for reading.




Recommended reading

37 comments ↓

#1 Farrukh Shahzad

STH Team,

Thanks a lot for sharing such a nice test automation series. All the tutorials were understandable, purposeful and consistent.
I am looking forward for such a good series of tutorials on test automation through Selenium web driver with C#.

Thank you again

With Best wishes and Regards
Farrukh Shahzad Ahmed
Islamabad Pakistan

#2 Mounesh

Good Job and very helpful

#3 Mehulkumar

very useful and practical series on automation.
kudos to team.

#4 kesav

Great Article… when anyone read this article can know about the detail info of the Automation testing

#5 Doris

A thoughtful article that can be utlized……

#6 Mohammad Saad

Thank you all for your nice feedback.

#7 saravana ragupathy

Thanks for sharing valuable information on this website.

#8 Anubhav

Good article and some good points raised. Though, on the point of UI automation, i don’t agree completely, as it also has it’s own importance with automation. But otherwise, a wonderful thought process put RIGHT. Thanks!!!

#9 Andrii

Thanks for the article, somehow agree with your point. But what is bad, is that you call people as a “resources”. This is true, but anyway to remind all the time, they people are just resources not a good idea.

#10 Roran

I agree with most of what you’ve written here. However, there is one point that I have a strong different opinion: Hire a Dedicated Automation Engineer or Team.

This should not be a requirement. Testers should be poly-skilled, in that, they should have the ability to outline the test approach wrt manually testing the AUT and also be technically inclined to start writing tests using test automation tools/frameworks. Hiring a separate team to only do test automation will create two teams (manual testing and automation teams) which essentially perform the same function – test the application. Having QAs who are poly-skilled will also help encourage collaboration between devs (who are technically more competent) and QAs (who may need some technical direction to get started).

#11 Auto QA

Automation can save time and resources, plus increase test coverage. In the past, many organizations found it to be either too expensive or too difficult to implement automation. However, today, through the use of open source tools, shared information, and more experienced engineers, test automation projects are worth the time and effort. The benefits usually outweigh the costs, assuming the automation suite is maintainable and portable.

#12 Parimal

Great article…thank you v much

#13 Nicolas Tremblay

Yes, this is a very good reference. 100% agree, but be careful with #10 which can become a mine field if you want to apply patterns to an extent that you risk delivering your tests too late. Pick your patterns carefully, we all know how difficult it is to deliver stable automation code quickly…

#14 Mohammed Asif

Excellent and useful article.
Keep sharing

#15 Maria H

This was a great article series, thanks a lot!

#16 srilakshmi

am a beginner in automated testing (coded ui) ,can i launch and close my application(windows application) for every test case? is tat a good practice ?if i dont do that then my test cases will be dependent on each other

#17 rob

How to do automation testing on a Widget in windows system tray overflow notification area…anybody experienced same issue

#18 Rakesh Priyatham

You just changed my perspective on automation testing. Thank you so much sir. :-)

#19 Dinesh

Very helpful. Thanks :-)

#20 A J Reddy

verry very useful this

#21 A J Reddy

verry very useful and helpful this tips. thank u

#22 A J Reddy

I agree with most of what you’ve written here. However, there is one point that I have a strong different opinion: Hire a Dedicated Automation Engineer or Team.

This should not be a requirement. Testers should be poly-skilled, in that, they should have the ability to outline the test approach wrt manually testing the AUT and also be technically inclined to start writing tests using test automation tools/frameworks. Hiring a separate team to only do test automation will create two teams (manual testing and automation teams) which essentially perform the same

#23 RaviK

Very nice article. Very easy to understand (real time example are too good)

Keep going on.

RaviK

#24 Ravi K

@A J Reddy,

In this article, I think (hire dedicated automation team) refered for efficient work.

#25 Mk

Nicely written.

#26 Shoaib Akhtar

It was very helpful. Keep it up..

#27 Lily

Very useful!
I like the article like this!

#28 Snehal B

Nice article!! like it!

#29 Selva

Very good article!!. It is very helpful for us…

#30 Srilekhya

Hi, That’s a wonderful article. I would like to devise a testing strategy for my product which runs on APIs.
I would need your inputs. Can I have any email id to which I can write my detailed query?

#31 Simon

Thanks for putting this together! 7 tutorials is a good amount, it breaks up a big topic into bite-size chunks without getting too granular. There’s some really salient points in here, especially the re-iterated advice about frameworks, designing and planning before getting stuck into test case engineering. My company is at risk of falling into this trap!
The above point brings me on to your advice about test automation architects – we don’t have one of those. Nominated developers will pick up this work for a given period of time. I don’t see this is as too outrageous BUT it does require that a wise choice of resource is made, someone who understands and respects testing, and the commitment to making our automation work for the long term (good maintainability), and to be flexible for new and changing applications.
You mention that automation will free up testers to do more testing of the application. This might be true but another possibility is that they could be free to work on something else altogether. I suspect this will be more attractive in my company, if the automation is a success.

#32 Shubhendu Chakraborty

Very nice and thanks for nicely presenting the reality along with technical approach. Good learning!

#33 DINESH KUMAR

very useful !

#34 Juan De Dios

Tienes un ejemplo en youtuve u otro lugar ,quiero aprender la automatizacion
Gracias

#35 Swati

Point 8 was really directional as I am looking for strategies to design and automate. It would be great if you can write something on how to break test scripts into smaller chunks, store them in repositories and then pull those chunks into a program to create an automated test script.

#36 Juraj

Great series. So glad I found this.

#37 Srinivas Reddy

We are very glad to have these tutorials, thanks a lot for your work.

Keep doing this on Automation testing upgrades if any.

Leave a Comment