15 Best Practices and Strategies for Test Automation
You might be wondering:
How professional Automation experts manages Test automation?
What all are the Practices & Strategies that they follow for a great Test Automation framework to survive in long term without any huddles?
In this blog,
I am going to reveal, some mandatory strategies to keep in mind while performing Test Automation on your project.
These are the exact points/checklist that I have consolidated from Software Testing Veterans or gurus Michael Bolton, James Bach and Cem Kaner and my own past experience of 5+ years.
Are you excited?
Say Yes…
Let's Start...
May be, You are going to start Test Automation project in your company but you are not confirmed what all are the best practices for Test Automation?
1
Contents
Choose the Right Test Automation Tool for Start.
Suppose,
If you want to do Automation for a Microsoft PC Desktop app, choosing Selenium as automation tool is clearly not a good decision.You should go with the AutoIT Tool.
Make sure you are clear with the advantages or disadvantages of that tool that you are going to use in Test Automation.
Do some POC and figure out early if it is handling your requirements or not.
“If there was one weapon he had against these savages, it was not acknowledging their existence.”
― Melina Marchetta, Finnikin of the Rock
Knowledge about the Other Test Automation tools and their pros and cons is must and You should avoid these naive mistakes while choosing Right tool for Automation.
Sometimes by losing a battle you find a new way to win the war. - Donald Trump
2
Use Design patterns in Test Automation for the God sake
There is famous quote
In the Test automation,
It is mandatory to code using well practices and pattern so that people can understand your code with minimum efforts.
“I'm not a great programmer; I'm just a good programmer with great habits.”
― Kent Beck
So you need to develop the good habits, and what are all Good habits in Test automation?
Design Patterns
Learn to use Page Object Pattern if you have working with the Selenium.
Never ever code in Spaghetti pattern where every test cases is tightly coupled with the Other Test case.
People have hard time understanding these kind of patterns and it will lead a bad impression on your colleges or senior resources.
My favorite quote about coding it that -
“Truth can only be found in one place: the code.”
― Robert C. Martin
3
You Can’t ignore the Naming convention
There are few rules that we need to follow for a clean code while creating a Test automation
Use below Rules to choose the Name of the variable.
4
Extensive use of the parameters and Data driven Testing.
Data driven is probably the best Testing framework to introduce in the Test automation. It basically means that the input variables, data or parameters are fetched from separate files like CSV,JSON,XML,ADO objects, ODBC sources rather than hard coding into the same test cases.
5
Do frequent refactoring whenever required for your test cases.
Refactoring means that changing the code to make it easier to understand without adding the extra functionality in the Test cases.
For your Test automation to succeed it is mandatory to refactor your code time to time
6
Implement Logs, screenshot , Reports like Professional.
If you are developing a Test automation,Screenshot and logs are used for debugging purpose and Test Automation reports are best to share the automation progress with the seniors or product owners.
7
Create custom wrappers for the utils or selenium methods for ease.
We should create some custom wrappers around utilities methods provided by automation framework such as Selenium.
These wrappers may not make sense for everyone or are not generic but they are very helpful for your project and hence makes your test automation great.
For example
We have created Custom wrapper or function to scrollTo X,Y position with the element, This kind of function is used by our Test Cases many times.
It is created as a custom wrapper using the selenium internal methods.
8
Stabilizing the Tests - The Hard Part
Most of the time, test cases fails due to some environmental issues or configuration issues.
We need to make sure that the a test cases should be stable as much as possible.
If they are flaky test, We should move them to a different test suite.
9
Create unique & Meaningful - Test data
For the test automation framework to succeed it is important that the test data should be meaningful and it should be as close to the users actions, behaviour.
I have noticed that testers uses some random data and due to that their test automation are not able to find bugs and so avoid this mistake.
10
Use Behaviour Driven Development whenever possible
Not everyone can understand you complex Automation framework test cases.
With the increased popularity of Cucumber(A famous BDD tool).
People are now moving to BDD framework for Test automation,
Where Test cases of in Test automation framework are written like normal language(like Given this then that) rather than complex structured programming code.
11
Include Alerts,Email Reports of Failure and flaky Test cases.
One of the important strategy or good Test automation is to have alert system inbuilt.
This can be email or alert with Test report or a Report containing number of Test cases failed per week/daily extra.
12
Avoid - Hardcoding input data or values.
Hard coding values for the input values is very dangerous,
I have seen people have hard coded the passwords of production server in the Automation framework or admin accounts credentials in the source code.
Please avoid this silly mistake.
13
Assign Default values
Clean code is an art, Always assign some default values to the variables in your Test automation code.
Not assigning default value is bad code practice and i have seen lots of Automation Test Cases failing due to the null checks extra due to this.
14
Use the Dry principle
In software engineering, don't repeat yourself (DRY) is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalisation to avoid redundancy.
15
Fail Fast and Do POC first.
Understand the business requirement and create 1 medium, 1 High level Test case automation as POC and figure out early if Test automation framework is handling your requirements or not.
Conclusion
What do you thing ?
Now I’d like to hear from you.
Maybe you have a question about something.
Or
Want to Share Your Awesome Strategy of Test Automation.
Either way, let me know by leaving a comment below right now.
Learn about the Software Testing and Test automation in Discussion.
Recommend Book of Post
Lessons Learned in Software Testing: A Context–Driven Approach
Decades of software testing experience condensed into the most important lessons learned. The world's leading software testing experts lend you their wisdom and years of experience to help you avoid the most common mistakes in testing software. Each lesson is an assertion related to software testing, followed by an explanation or example that shows you the how, when, and why of the testing lesson. More than just tips, tricks, and pitfalls to avoid.
Thanks Promode for sharing your experience with us.
I’d like to share with you my experience regarding your best practices:
1. Choosing the right automation tool for the job is indeed key. But note that this should be a secondary decision, after you decided who should write the tests, analyzed the architecture and the interfaces between the automation and the SUT, etc. Anyway, there are many great tools for UI automation on the PC other than AutoIT…
2. Design patterns are also very important. But there’s much much more to design patterns beyond page objects (and the general advise to not write spaghetti code…). Moreover, beyond design patterns, there are design *principles*, like the SOLID principles or the 4 Rules of Simple Design by Kent Beck.
3. Naming conventions goes way beyond variables and the general advise you give. The most important names in test automation are those of the tests, and of the test classes. But overall, the most important advise is to name things in a manner that describes their intent.
4. Data-driven tests are great to remove duplication, but they should only be used where appropriate. I saw many cases where DDT were overused. After all, most tests should describe different scenarios and not just different data. Make sure that the different data rows really add value and whether the test code does not have “if” statements that are needed to support different rows. If it is, then I advise against DDT. Remember: while the application code should be generic, the test code should be as specific as possible
5. Agree
6. Agree, but the main purpose should be to help you investigate failures quickly. For your managers and product owner I prefer summarizing the results using my own words
7. This is also something that is too often abused. You should only wrap utils that add value. Many people creates wrappers around Selenium that mainly restrict its usage. If you create a wrapper for something, make sure that you don’t restrict its usage unless you have a good reason to.
8. I agree with the title, but not with the content: Most often, “environment” issues are a symptom of bad design of the tests! Flaky tests should be thoroughly investigated (e.g. by running them in a tight loop) and not just thrown over to another suite.
9. IMHO it’s usually best that each test creates its own data. The data don’t have to be meaningful from a user standpoint. It should be meaningful to the purpose of the test. For example, you may add a product named “ProductWithDiscount” in a test that verifies the discount calculation engine.
10. BDD is great, but the tooling (Cucumber) is a very small and insignificant part of it. BDD is about the methodology of driving *development* according to the described behaviors. I prefer the term ATDD – Acceptance Test Driven Development, that describes pretty much the same thing
11. I prefer that the tests be run as part of CI, and that developers know that they don’t check-in code while the build is broken. In this case, alerts are redundant.
12. Hard-coding passwords maybe a security violation (though in test environments is not always a real issue). Things that need to change often should generally not be hard-coded. It’s completely OK to hard-code other values, as long as each appears only once in the code
13. This is just one tip of clean code. I’m trying to avoid nulls wherever possible.
14. This is my favorite principle 🙂
15. Agree.
Much more information can be found in my book “Complete Guide to Test Automation” available at https://apress.com/us/book/9781484238318 and on Amazon.
Thanks for wonderful share. Appreciated 😊
Hello, The most important names in test automation are those of the tests, and of the test classes. But overall, the most important advice is to name things in a manner that describes their intent.
Thanks