Testing Automation With Selenium - Part 1

Never send a human to do a machine’s job

Testing a CRM application which I am part of became very difficult over the recent months. There were simply too many usecases. Despite unit testing on the backend services (SOA), bugs crept in on a regular basis considering a lot of logic is on the javascript and other layers of the application.

This is Part 1 of this series explaining how the following problems that I faced during testing were addressed :

  • There were too many combinations of test scenarios

  • Application logic was spread over javascript, front-end, service and database tiers

  • Existing testcases for services/portals are not exhaustive

  • Our Unit testcases verified against static data

  • Enabling/disabling/visibility/invisibility of fields on the front end could not be verified by plain Unit tests

  • Incremental failure built inside JUnit testcases is not always useful. A report of all the issues would be nice.

The itch and the scratch

The Tool was built upon Selenium, Spring and Velocity.

Tool Stack

The following features were built into the tool

Problem vs Feature

Problem vs Feature


As part of the web automation, a series of utility methods was written/stolen from various sources. I am sure you’ll find the SeleniumUtils class interesting and useful.

Meet you until next part…