Selenium WebDriver Model
Regression Test Automation with Selenium WebDriver
The majority of current software applications are developed as web-based applications, running on web browsers such as Internet Explorer, Mozilla Firefox, or Chrome. Web applications create a specific load on software testing resources, as the combinations in browser and platform coverage add to test coverage complexity. Most of these applications are being developed with some kind of Agile methodology, which provides additional challenges in quality assurance. In this process, test automation is mandatory requirement to improve quality assurance, reduce timelines, as well as provide a regression base for the life of the application.
One of the most effective tools on market for automated functional and regression software testing is Selenium WebDriver. For the past years, Selenium went through its own evolution process from Firefox browser add-in to its current version, which provides a large variety of features including more cohesive and object-oriented APIs. Selenium automated frameworks support different browsers, data interfaces, environments and programming languages such as Java, C#, Ruby, and Python. The additional features in Selenium frameworks require a higher level of base knowledge from an automation engineer as compared to the previous generation of systems, but being an open-source platform still makes it very attractive to a wide variety of companies.
Reusability and maintainability of any Selenium framework is supported by a multi-layered framework concept, as described in a previous SPR blog. This concept requires robust planning up front, but helps test automation engineers maintain and support future testing with ease. The main components of each layer for a Selenium WebDriver application are:
- Abstract layer
BaseTest – a class that initiates Selenium WebDriver and invokes the browser, passing some of the key settings. This is called at the start of every test case, and contains the corresponding annotations to be used in the test environment.
BasePage – a class for generic page validation. The main purpose is to keep all custom methods in this class. As an example, instead of using the “click” method built into Selenium, we develop a custom method (let’s call it “clickOnButton”) that will also include validation before clicking on an element, as well as the actual click and verification that an expected result is achieved. The methods in this BasePage class are highly generic methods that require all specific parameters such as ID etc. to be passed from higher levels in the framework.
The abstract layer will also contain other classes, many of which may already have been created and easily available from another Selenium open-source project. These may include a DatabaseConnection (for access to SQL or other back-end queries), Log, Report, API interfaces, or other utilities to be accessed by the rest of the automation solution, depending on what the functionality may be in the project configuration. - Application Layer
Depending on which type of automation framework (data-driver, modular, or a hybrid of the two), the applications layer will be required to store some application-specific reusable generic methods and functions, and be written to pass information about these methods and functions between the Application Test and Abstract layers. In this case, we are talking about a Selenium page factory (also known as object repository), validations and test methods. This repository represents each item and function on each screen to be tested in the Web application, in such a way that simplifies development of the automated test case, and facilitates passing of necessary information down to the Abstract layer. - Application Tests
The Application Test layer is meant to be non-technical code, so anyone can read and understand what the test is supposed to accomplish. The Application Test programmer should not have to be a highly skilled Java (or whatever language is being used in this WebDriver solution) programmer to write and comment the test code. All the text inputs, data parameters, SQL queries, log and error messages are created in this layer to execute a WebDriver test, but this is information that should have been known and documented regardless of how the test was executed, whether via automation or manual execution.
Each of above framework layers depends, in its own way, on the project architecture and requirements. The Abstract exists to provide specific ways of storing and accessing data. The Application Layer exists to drive each functional unit to be tested. If both layers are well-built, the engineer writing the Application Test code does not have to understand any details to know how to drive the application, the access details of a database server, or clearly delineate whether logs and errors are being stored in Excel, text files, or a customized testing tool. For example, a change to an API only effects the Abstract Layer; a coding change to the application under test only effects the Application Layer. In either case, the Application Test code itself remains unchanged. Conversely, if text or a label changes in the application, but the underlying objects remain the same, only the Application Test is modified.
By implementing the appropriate automated testing framework, enterprises can significantly increase the speed and accuracy of the testing process, provide a higher return on investment from software projects and systematically control and minimize risk.