Demanding customers and aggressive GTM strategies have made the Software industry innovate on multiple dimensions. One of those has been innovation in Quality. Going beyond the traditional means of verification and validation manually had been a luxury for some time but not anymore. Today, Test Automation is one of the most promising ways of expediting testing and eventually crunching the test cycle making aggressive GTM possible.
Though this is true, a mere 14% are successful and achieve the promised benefits of Test Automation which means a significant majority of them doesn't get it right. Today we will try and understand what few do right and where most go wrong.
Unlike early days of test automation almost every automation tester today understands that test automation is not about record and playback.
To ensure that test automation holds ground against functional changes in the application and continues producing accurate, dependable results in no time, a definite planned strategy and frameworks are required based on the application / product being automated.
There are several frameworks used beginning from simple modular frameworks to more matured ones like Data Driven, Keyword Driven, Hybrid, etc...
I am sure this is not news to most of the test automation experts today. Having said that, the success rates are not very encouraging.
In my years of working with different teams and businesses in Test automation, here are some of the factors that in my opinion are key to Test Automation success.
The Right Team
As we would expect the first thing is to identify and formulate a team that understands test automation. Having said that, having developers in your team is a highly advisable.
As framework development is a thorough Software development process, developers with the required tools experts makes a perfect team.
Such a team would be completely responsible to Design, Develop, Maintain and Support the framework.
In my opinion a Leader of authority with strong development skills needs to head this highly motivated team of Automation Experts and developers. Other than providing direction to the team a leader should actively participate in design, development of key components (if possible), being in tune with stakeholders on their demands from automation, vision for the framework, and of course complete ownership of its success and failure.
Most frameworks that get developed have the teams required but start with an incomplete objective. For e.g the best team might be asked to automate an application using a tool, they automate the application and in the process build a framework with certain generic code libraries. This is a classical example of an incorrect objective. Here the objective is to automate the application and not to build a framework.
Well designed, robust Frameworks are only built when the objectives are absolutely clear and well communicated across the team. For e.g. One of the Framework development objectives can be to build a Framework that will help Se Users automate quickly.
While working on building the best of the grade frameworks its worth taking note of the following guidelines that teams have used to build successful frameworks.
- List as many Objectives as possible as that gives your vision the clarity required.
- Aim for as much re-usability as possible (re-usability across applications, across technologies
- Use your manual tester’s application and domain expertise for automation. Build Framework that is manual tester friendly
- Ensure that Test execution results accurately show the status. Failure/Issues if any are notified with possible causes.
- Framework must be easily adaptable by any user (if possible even by a manual tester without any tool knowledge)
- Designate a clear Maintenance and support team as framework maturing and enhancement is a continuous process.
- Have a robust object management strategy and design. This really goes a long way as its one of the key aspects of making your framework scalable.
Thus far, one of the biggest challenges of Test automation has been adapting to the change in the underlying application. Change to the application is an accepted fact and frameworks should account for it. There are multiple facets in test automation that are susceptible to change like Objects Information, Data, Work flows. Commonly frameworks account for Object Information and Data changes but that doesn't seem enough as 80% of the change in an application lifecyle is in the workflow. An evolving application, during its devleopement lifecycle adds new functionality, new objects, etc... which contribute to new or changed work flows. A more robust framework needs to arrest this workflow based change to take complete control.