Managing selenium for automation testing

I’m a big selenium enthusiasts, as this is an open source tool with many possibilities. Because it’s an opensource tool, it’s one of the more widely used tools in the testing industry. During the years I’m using selenium I have come to a standard framework to accelerate the start of a new automation projects.  One part of the framework is in code, the other part is the vision behind the framework to manage the setup of the automation project.

The Base

In my framework there are 3 layers that function together and each of the layer adds something, to make the test scripts easier to read, write and maintain. The basis is the standard selenium packages together with TestNG. These 2 packages are the foundation of the framework which will be build on and used to enhance the framework. As I think the selenium package is obvious, maybe TestNG needs some explanation.


TestNG has some nice extra’s you can use to add and build in your automation project. One of the better features I use are the test xml files. In a test xml you can define which classes need to be run or reduce this to only several method of specific classes. With this you can limit the amount of testcases for specific purposes, like time reduction or testcases on certain feature of the tested software. Inside these test xml’s you can also set variables that will give values to your code from the xml file, so you will have a wide array of possibilities of customization in the xml to adjust a testcase. For example one of the variables I set, will determine the browser that will be set up for the testcase. In this way I can only test one browser like chrome. But if I need to test the other browsers, it’s just a parameter to edit and the test will run in firefox or any other browser that has been setup in the framework. Another example is a specific kind of test I build. As time goes on the amount of tests will grow, more tests equals longer execution time. To tackle this issue I prioritized several test and create a release test xml. So whenever a new release is being build, this script can run and have a view on what these specific tests give as a result. In this way we can determine if it’s okay to release the version or not. The complete test set will run daily to check if the application is still ok, and no new issues are created.

Easy to use methods

The second layer of the framework are methods and classes to reduce code duplication. These are classes for movement, like clicks, reloads, typing which will have specific methods for different ways of determining the object (xpath, name,Text inside the object). Next to this I have classes to setup the different browsers, take screenshots and to the testing checks.

Project specific layer

The last layer of the framework are more project specific classes. Like an abstract class with all the menu options. A class to press the specific buttons from the application. In this way you can also create more readable scripts. Next to the readability is the reduction in time to create these scripts. But also don’t forget it makes your code easy to maintain. Whenever in the application some button changes or disappears, we can just edit or delete this. With the edit, all the different testcases that use this method will automatically use the new setup.

These three layers will reduce the time needed to create the test scripts. Will make them more readable as the names are clear for technical and non-technical persons. But also easy to maintain to reduce the time needed to maintain it and spend it at writing testcases.

Please follow and like us:

Add a Comment

Your email address will not be published. Required fields are marked *