UI Automation Basics

Is the scope of your application expanding? Is your team trying to be agile but spending too much time regression testing your app? Would you like to know the quality of your app as you’re building it? If you’ve answered yes to any of these questions, your team (and specifically your QA staff) is especially in need of TESTING AUTOMATION. Who wants to spend their time regressing a product each release when they could be spending more time with the customer or helping to design features. I certainly don’t.

I currently work on a product that’s about 10 years old. Over those ten years, it has grown, shrunk, and grown again to the point that it was becoming hard to ensure a high level of quality from release to release. In order to assist the team in the lengthly process of testing the app across areas, browsers and configurations, I began to build a UI testing framework. A unit testing framework had already been developed by the team, but we needed a way to ensure the integrity of the app across browsers as new features were being added. Here were a couple of requirements that we had in place:

  • With an expanding team, the UI was constantly changing. The UI automation framework must be maintainable to prevent constant refresh of tests due to a changing UI.
  • Tests must be written once and have the ability to be executed across environments and browsers seamlessly.
  • Triage must be quick and painless.
  • Tests should be easy to read/write by QA engineers and product developers alike.
  • Tests should be decoupled from the underlying automation tool to allow for swapping out of the framework. We weren’t entirely certain which tool we wanted to use (Selenium, Silk4J, WebDriver, etc) and didn’t want to have to start from scratch months down the line.

Over the next few posts, I’ll be detailing how we accomplished all of the goals listed above and how you too can help your team become more agile by testing faster and more effectively.