Building a robust test automation strategy - Shreejit Nair

Here is an excellent article by one of my good friend Shreejit:
I believe most test automation frameworks never succeed or kick off not necessarily due to a lack of technical skills but a poor understanding of the big picture by test automation engineers.
I have tried together to put in some points that I believe are important parameters to be considered before deep diving into test automation.
 Behavioral expectations as a test automation engineer:
 1. DO NOT BE TOOL OBSESSED - This is often a critical mistake test automation engineers make, trying to bend a tool that they have experience with to fulfill a given purpose or situation. We need to realize that every product/every team    and their needs are different.
 2. Do not think purely from a test automation perspective with an intention to build a framework by adding or bundling together a few functions. Building a robust test automation framework is far more than that. Most importantly,understand your software ecosystem, how the dev/qa/scrum masters/product owners/environment guys work together on a daily basis. Understanding how they work would help you design a framework that is more usable to them than any of the industry recommended patterns or frameworks that you might have heard off.
 3. Do not be hesitant to manually test the product. I have often come across test automation engineers who are hesitant to manually test a product, who expect perfect test cases to be written across before they start with the automation work. I would advise you to test the product, breathe it, recognize the challenges from the inside out, understand the bottlenecks in the application which slows delivery and delays release schedules.
 4. Do not aim for perfection from Day1. Build a smoke test that works today, will work tomorrow and iterate and maintain it, work relentlessly in trying to improve the framework. Consider it as your baby.
 5. Test automation is software development. Convince your team and managers about it.
 6. Most importantly - Handling Management expectations.You cannot proceed much without having management on your side (you already knew that :) ).Do not give High level estimates that the framework would take months as per industry standards and stuff. No, it would never get approved.Build a prototype, automate a happy path/smoke test scenario get a working demo out as soon as possible. Get management on your side. Once they believe in you that's half the battle won.Once you gain their trust that would be a good time to achieve perfection (Page Object Model frameworks / re usable components / maintenance utilities). Trust me, you would now get time to pamper your baby.Making management understand the importance of test automation, making them believe and invest in your idea is probably your biggest challenge.
 7. There are really only two steps: 1. Development - Build out the framework, implement test cases in a language the business user talks in (domain specific language). 2. Maintenance - Things will not always be smooth. Build smart utilities that could help in maintenance issues (object modifications, new test paths in existing scenarios). This is where "automating the automation" idea is most helpful.
 8. Handling the "how long will the framework take" dreaded question. Not advisable to throw in figures till you have a working POC ready. It is important to pick up a happy path scenario and also having a vision for the most complicated test scenario in the pack. Many frameworks do not go beyond the 'demo' stage since engineers might not have factored in complexities involved in really convoluted test scenarios. Always estimate for development and maintenance including keeping complexity of the scenarios in mind.
 Technical considerations:
 1. Never never build a framework with low level steps (Clicks,Wait, and so on.....) exposed on a front end layer.
2. Always have business keywords/components exposed on the front end layer (RegisterUser,CheckoutProduct,MakePayment).
3. Build strong abstraction layers. The whole point is hiding complexity, making your life miserable by writing a hell lot of code but the layer exposed for end users to quickly add tests should be simple and beautiful. Ideally, the amount of test code    should mimic production code.
4. Front end layer to add tests could be excel/fitnesse wikis/xml/gherkins for ease of users to quickly add tests.
If you are an automation engineer or looking to build your next test framework drop a note and let me know your thoughts.


Popular posts from this blog

Trim / Remove spaces in Xpath?

Complete list of Serenity properties

XPATH for IE / internet explorer