How to Select Test Automation Tool

Test Automation Tool can play a big role in deciding success as well as effectiveness of Test Automation. Based on the growth in the device and browser matrix, it is not recommended to build test automation framework around a single tool; however, many organizations still continue to do so. It becomes even more important to choose right tool for your automation when test automation solution is built around a specific tool.

Test Automation tool along with its associated components are primarily responsible for communicating with Application Under Test (AUT) and for passing the instructions of test automation scripts to AUT interface (UI or API) and get responses from the AUT interfaces. The tool is also responsible for verification of the AUT responses against expected results, logging of results and report generation. Other than these basic responsibilities, the test automation tool has enhanced features such as keyword driven scripting, robustness against failures / unexpected interrupts, informative dashboard which shows progress of test automation while executing, integration with test management tools, integration with continuous integration tools, etc.

Best way to approach selection of test automation tool is to do an elaborate Proof of Concept (POC) with AUT using the tool. Most complex test scenarios (e.g. boundary conditions, large test data volume scenarios, scenarios involving boundary conditions, etc.) should be put to automation using the tool.

More than one tools must be tried for the POC and the parameters such as

• Browsers / Devices / OSs Matrix Support
• Extension Features – Ability to integrate with Industry standard automation frameworks / components
• Technology Support – Ability to support different programming languages
• Possible test coverage of AUT
• Community Support – Extent of available help documentation, active forums / discussions regarding the tool
• Richness of tool development interface
• Ability to integrate with (desired) test management tools
• Ability to integrate with (desired) continuous integration tools
• Licensing mode (SaaS Vs Perpetual Licensing, Node locked Vs. Floating Licenses)

As ever, the IT industry continues to evolve with different technologies and gadgets. Against popular Windows desktop based UI applications of 1990s, distributed web applications are now ubiquitous and eventually will be replaced by applications on small form factor (SFF) devices. Commercial tools with initial focus on UI automation of Windows desktop applications eventually evolved to support Web applications / Web Services and are trying to catch up with UI automation on SFF devices. Many open source / freeware tools and libraries, have become equally popular and successful in addressing test automation needs (e.g. Selenium, Microsoft UI Automation Libraries, White, Sikuli, Appium, Calabash, etc.)

Typical enterprise application under test (AUT) is likely to be comprised of Data layer, Services Layers and User Interface layer. At the data layer one has choices of SQL / NOSQL technologies. For data transport there are choices like XML vs. JSON vs. custom data structures. Also one may choose to hide / expose service (API) layer along with UI layer external users. UI layer itself needs to support leading browsers (IE, Firefox, Safari, Chrome, Opera) and mobile technologies like Android, iOS, Windows Phone, etc.

Most of the applications are likely to support all leading devices as well as browsers. It is going to be difficult for any single tool to be able to keep up with the pace at which this matrix is growing. Hence single tool cannot provide foolproof test automation solution against diverse platforms.

Recommended approach is to separate framework development activity from test automation tool selection activity. Test automation framework should be robust enough to accommodate multiple test automation tools, libraries for different test automation needs (e.g. UI testing, API testing, Volume testing, Performance testing, Vulnerability testing). Each tool selection can then undergo elaborate POC as described above and consequent integration with existing test automation framework.