This article focuses on examining the top foremost Test Automation Strategies and best practices. This article marks the conclusion of the test automation series.
While we have mentioned some best practices in our previous articles (which may be repeated here), I wanted to compile a list of automation best practices in one article for easy reference.
These strategies are taken from my experience plus from the literature of testing gurus like Michael Bolton, James Bach, and Cem Kaner. Every automation project should follow these practices.
Table of Contents:
- Test Automation: Effective Strategies and Practices
- #1) Hire a Dedicated Automation Engineer or Team
- #2) Automation Tools Are Important But it’s Not Ultimate Solution
- #3) Select Well Acquainted Automation Tool For Your Resources
- #4) Know That Application is Being Tested
- #5) Good Automation is a Good Manual Test Case
- #6) Identify Opportunities With Automation
- #7) You Cannot Automate Everything
- #8) Avoid GUI Automation In case of Alternative Solution
- #9) Use Automation For Other Useful Purposes As Well
- #10) Automation is Software Development
- Conclusion
Test Automation: Effective Strategies and Practices
It is time to initiate our examination of the most efficient strategies and recommended practices.
#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 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 comprising at least one automation architect. You can hire multiple automation engineers to work under the guidance of a test automation architect. The number of automation engineers depends on the number and size of your products.
#2) Automation Tools Are Important But it’s Not Ultimate Solution
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. It makes the process easier. However, you need skilled resources to complete the process.
Often automation tools are buggy and they are stuck in identifying complex objects on the application. The resources you hire, if they are skilled, come up with a workaround that takes the process forward. Otherwise, if you don’t hire good resources, tools alone cannot guarantee successful automation.
#3) Select Well Acquainted Automation Tool For 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 that offers a minimal learning curve.
#4) Know That Application is Being Tested
The tool selection depends heavily on the technology used in your product. Know your product inside out before starting the automation.
When dealing with a web application, it is crucial to ascertain the browsers that it will function on. Acquire knowledge about the technologies employed in it.
For desktop applications, it is necessary to identify the programming language on which they are built. What third-party controls are being used in the application? This will contribute to the ease of tool selection and enhance future automation efforts.
#5) Good Automation is a Good Manual Test Case
Well-crafted strong manual test cases save us from automating those test cases which are easy to automate but weak in finding defects.
Here is a 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 clearly and write expected results in front of each step. The aim of one test case should be clear and it should be less dependent on the other test cases.
Automation engineers should manually run this test case at least once to clearly decide the objects that need to be identified and the flow of navigation. Ask questions for manual testers.
This activity sometimes helps to identify bugs even before the automation script is written. According to experts, the majority of bugs are discovered during the test automation development phase rather than during the 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, look for additional opportunities in your automation to broaden the scope of this test case.
For example, if the manual test case requirement is that you have to login to a web page. You can expand this test case by making it data-driven. List all the 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 results in an excel file and put this excel file as a data source to your test case. Once this particular manual test case has been automated, it is capable of testing all potential scenarios simultaneously.
Always look for opportunities that require automation and are difficult to do manually. Manual testers often encounter challenging scenarios such as Load Testing, Performance Benchmarks, Testing in varying environments with different configurations, Memory Leaks, and High Precision Tests.
#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. However, it is essential to ensure that every test is automated, as this allows a manual tester to allocate their time towards more crucial tasks.
Automation is not here to replace manual testers. It takes the repeated work away from manual testers so that they can use their full focus and strength to find new testing scenarios and bugs.
Recommended Reading =>> Misconceptions of test automation
Automate a few tests that are valuable and time savers or difficult to do for manual testers. If you do that, the task of automation is done.
#8) Avoid GUI Automation In case of Alternative Solution
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 or not the application is installed 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 and time-consuming and it is subject to maintenance if UI changes.
An alternative approach entails using a batch file to initiate the installation of the application, employing 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 a fantastic thing. You can achieve 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 soon as possible.
I can give one example from my own company. Our intention was 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 have 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 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 generated an Excel file with a specific format by writing an SQL query to fetch all test cases and bugs. I proceeded to use a tool that extracts all test cases and bugs from the excel file and inserts them into TFS. In just 3 hours, the whole process was completed. My manager was extremely pleased. I also hope that my point is clear to you.
#10) Automation is Software Development
Developing quality software requires best practices. We need 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 in automation should be reported in the bug repository. Automation source code 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 have done as well. Test automation is an interesting and rewarding career. Doing it right has benefits for both you and the organization.
Every day while working on test automation and its techniques, I find new and interesting challenges to solve. The series was an attempt to highlight what could come across in the journey of test automation. I hope I was able to deliver it correctly in a simple manner.
We await your suggestions about this post. Feel free to write your feedback in the comments section below. We will be happy to hear from you and help you if needed. Thanks for reading.
Was this helpful?
Recommended Reading
-
Comprehensive list of the best Software Testing Tools. Put an end to your search for the right Manual or Automated Testing Tool with this informative list: We are happy to present this exclusive list of the most popular QA Testing Tools that are available in the market. Get Ready To…
-
Read This Informative Article to Understand the Differences Between Manual Testing Vs Automation Testing Along with Scenarios Where Automation Can be Used: Software Testing is the process that is carried out throughout software development. It is the process of checking, verifying, and validating the requirements of the product. We are…
-
From designing a strategy to picking right solutions, here are 5 steps to transition from manual to automation testing successfully. Automated tests can minimize regression bugs and overcome multiple manual testing challenges, enabling teams to deliver more qualified applications. That’s why many teams are transitioning from manual to automated testing.…
-
If you are doing manual testing of your project and decide to go for Automation I think you will have to ask yourself some basic questions like Which is the best testing tool? To which level should I automate project Testing? Is it possible to Automate my complete application
-
Here is the Complete Guide to start Automation Testing on Your Project. Let's get started. Let us first understand what Automation Testing is? Automation testing is a Software testing technique to test and compare the actual outcome with the expected outcome. This can be achieved by writing test scripts or…
Very useful!
I like the article like this!
verry very useful this
Very nice and thanks for nicely presenting the reality along with technical approach. Good learning!
Is it ever a good idea to have your Developers write test automation? For instance, if there is a lack of QA resources, would it be an acceptable path to have Developers take on that task?
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!!!
very useful !
Great Article… when anyone read this article can know about the detail info of the Automation testing
Good article thanks for sharing the valuable information. We are a small team of 5 developing a web-based application and follow agile method. Hiring the automation engineers and paid tools like UFT were more expensive for small companies like us.we had opted for a tool called CloudQA thru a referral discount from a close friend. We saved a lot of money. However there were a few compromises, it didn’t support the drag and drop control out of the box. As said in point no 8 above this tool can’t automate functional testing until the GUI is ready. Overall we’re happy with it.
Great article…thank you v much
Very Useful Article.
“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.”
Thank you so much
Nice article!! like it!
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
verry very useful and helpful this tips. thank u
Very nice article. Very easy to understand (real time example are too good)
Keep going on.
RaviK
Excellent and useful article.
Keep sharing
This was a great article series, thanks a lot!
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
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
@A J Reddy,
In this article, I think (hire dedicated automation team) refered for efficient work.
could you please tell me the tool used for to read test cases and bugs from an excel file and insert in TFS
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…
Thank you all for your nice feedback.
Good Job and very helpful
Very good article!!. It is very helpful for us…
Thanks for sharing valuable information on this website.
We are very glad to have these tutorials, thanks a lot for your work.
Keep doing this on Automation testing upgrades if any.
Tienes un ejemplo en youtuve u otro lugar ,quiero aprender la automatizacion
Gracias
A thoughtful article that can be utlized……
Nicely written.
How to do automation testing on a Widget in windows system tray overflow notification area…anybody experienced same issue
It was very helpful. Keep it up..
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.
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.
You just changed my perspective on automation testing. Thank you so much sir. 🙂
Thank you so much!
This has been an amazing read, just wow, the way you explain and with the examples given. Thank you so much!
How you organized your Test Automation resources?
can anyone answer this question?
thank you in advance
Such a great tutorial. Being a tester working at a software test automation services providing company(narwalinc.com), I cleared many of my doubts by studying this article. Thanks for sharing this.
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?
very useful and practical series on automation.
kudos to team.
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.
Thanks,
Quite Good Stuff!!
As I am a Trainee At Bugraptors this information is very helpful for me for future reference.
Very helpful. Thanks 🙂
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).
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.
Awesome Article!! Learned a lot. Great job!!
Interesting, some of this items are just the opposite that my organizations think about automation, I always talk about this, but the primary group, that commands the automation in the company do or go to the opposite.
My company it’s one of the most famous and big players in the IT market. Present globally and leader of the segment.
Great series. So glad I found this.