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.

Comments

Post a Comment

Popular posts from this blog

Software Testing @ Microsoft

Image
In continuation from my previous  series of posts  targeting testing in top few companies from the technology space. After  Software Testing @Facebook  and @Google  we shall now look at Microsoft: Testing@Microsoft Software Development Engineers in Test (SDETs) are usually just called Test and sometimes Software Testing. SDETs are responsible for maintaining high testing and qualityassurance standards for all Microsoft products. Software Development Engineers (SDEs) are often referred to as Software Development. SDEs write the code that drives Microsoft products and upgrades. Very few teams in Microsoft are still using SDETs to do significant amount of manual testing. Manual testing is mainly outsourced. Actually, as early as in 2004, for example, most of the manual testing of MSN Explorer was outsourced. Think about it this way: it just doesn't make sense for test manager to spend their headcount (SDETs) on something can be easily outsourced.  Until 2005, Microso
Read more

Trim / Remove spaces in Xpath?

Image
If you are wondering how you can trim the spaces in your xpath, this is how: The normalize-space function strips leading and trailing white-space from a string, replaces sequences of white-space characters by a single space, and returns the resulting string. Example : Which one is better? //td[starts-with(normalize-space(),'Text to Trim')] //td[starts-with(normalize-space(text()),' Text to Trim ')] The second option is better as it targets at the specific nodes More string functions in XPATH: Functions Description starts-with( string1 ,  string2 ) Returns true if the first string starts with the second string. contains( string1 ,  string2 ) Returns true if the first string contains the second string. substring( string offset length ) Returns a section of the string. The section starts at  offset (which is a number), and is as long as the value provided at  length. substring-before( string1 ,  string2 ) Returns the part of  string1  up unti
Read more