Chances are, if you are responsible for the testing of web applications for your organization, you’ve explored or at least heard of Selenium as a potential automation tool. And why not? It’s open source, so no sticker shock on licensing fees. Better yet, no yearly maintenance fees. But just as multiple challenges exist when implementing purchased automation tools; there is much consideration that must be taken when selecting the right automation tools for your test efforts. Selenium possesses many of the same hurdles and throws additional ones into the mix.
- Lack of advanced framework design
- No long-term road map
- Programing the selenium automation in another language
- Building an overly complex automation suite
- No dedicated team for maintenance
1. Lack of an advanced framework design that will promote scalability and maintainability
Creating automated tests that provide real value because they are actually used and can be maintained and scaled relatively easily is vital to the success of any automation implementation. This is where an advanced automation framework does the heavy lifting. Advanced frameworks succeed in reducing maintenance and increasing scalability because they:
- Separate the data from the tests using solid externalization methods
- Provide a single point of maintenance for data, objects, and navigation
- Manage object property identifiers efficiently
- Modularize navigation effectively for reuse
- Recognize that separation is needed between automation users and automation engineers
2. No long-term road map
Too often we see companies rush to automate before stopping to consider what is necessary to keep automation viable and relevant as the IT organization grows and changes. Before you automate, consider these items:
- What are the organization’s future technology and platform changes that may limit automation or render it obsolete? Do we build an automation suite that is more complex and flexible enough to accommodate those modifications, or do we plan on implementing an additional automation effort in the future and switch over at the appropriate time?
- What is our test data strategy? Automation can consume vast amounts of test data if it’s a large baseline and runs frequently. Ensure you have a test data strategy that can handle it. Explore using the automated tool itself to create the test data automatically versus manually.
- Who will champion the automation after implementation and provide guidance and direction to ensure it continues to bring value to the organization? Who will perform the maintenance and enhancements of the baseline?
Ensure you have well thought out answers to all these questions to get the most from your automation effort.
3. Programming the Selenium automation suite in a language other than the core competency of your development organization
Your development organization may be a Java shop but suppose the person tasked with creating the Selenium automation suite knows Ruby really well? He or she lobbies to build the suite in Ruby and it may seem like a good idea at first. But this can backfire. If the person leaves, or if someone else is tasked to maintain the tool, what happens if the new person doesn’t know Ruby as well or at all? Had the framework been built in Java, there is a whole department of developers with that skill who could lend assistance. Unless there are other compelling factors to build the automation in a language other than your development group’s core competency, avoid the urge to create it using the language of choice dictated by the person tasked to build it.
4. Building an overly complex automation suite that does not meet the testing needs
Even though automation is intended as a testing function, the creation of it is truly a development effort. Given this, developers in many companies are often asked to bring Selenium automation to life. This is a valid solution if your organization can allocate development resources toward this effort. However, someone on the team must ensure the solution under development actually meets the testing needs (and business needs) of the organization and the resulting suite is not too complex for others in the organization to maintain. At some point, the developers will want to move back onto the core products and cutting edge development that drives the business. The maintenance of the suite will fall into the hands of testers and other personnel that may not be as technical as the front line developers. Go for simplicity in your automation solutions whenever possible and stop to ask each step of the way, “Is this truly addressing our testing needs.”
5. No dedicated team for maintenance and enhancements to increase test coverage
This is an extension of item number 2 above, but is important enough to elaborate. Automation needs care and feeding. Ignore it and all the effort concentrated on the automation implementation vanishes as the suite loses relevancy quickly. Even when an automation suite has been designed for easier maintenance, there will always be work necessary to keep it up-to-date. If an organization is not going to have one or more people dedicated to maintain and enhance the automation suite moving forward, then you really have to ask why the organization should invest in the initial effort in the first place. This may seem like common sense, but many companies have spent vast sums of money on automation implementations only to let them languish because there were no solid plans for maintaining them.
From Zenergy’s perspective, Selenium will continue to gain traction in companies where web applications drive business. But to truly reap the benefits, organizations need to consider all aspects of implementing test automation, from overall framework design to on-going maintenance and support, before making the investment.
If you’d like some guidance in your automation implementation, please reach out to us for a no-pressure conversation. We are happy to give advice and point you in the right direction, even if you don’t plan on using automation consulting services.