Test automation is a critical feature for any company working with technical/software projects. It provides number of advantages to a system’s build process. To name a few:
- Regression testing can be done more efficiently
- Some repetitive tests—or even business processes—are executed faster
- Compatibility testing can be done in parallel
- Defects are found in earlier stages of a project
When we started implementing our first automation projects at Oshyn, we noticed some limitations with native Selenium. All the issues we saw could be resolved or improved by implementing a custom framework that completely wraps up the necessary Selenium logic—so we built the Oshyn Automation Framework. The following list summarizes these issues and describes our solution for each:
Issue: Locators are hard-coded in the source code. When using native Selenium, it’s mandatory to include the control locators in backend code or using attributes. This could cause a couple of issues in the future. First, it’s pretty easy to duplicate controls. Second, the maintenance work involved in changing/updating the locators could be cumbersome.
Our Solution: The Oshyn framework uses separate XML files to centralize the locators that are going to be used in the automation project. This turns the maintenance work into a more flexible process and reduces the risk of duplicate locators.
Issue: Selenium is an API that needs to be consumed/customized per project. This means every project needs to be rewritten from scratch even if we are implementing similar test scenarios. This can add time and cost to our projects.
Our Solution: The Oshyn framework implements a crawler that is able to analyze any website in minutes and automatically generate the core/basic UI tests. We simply have to manually write down the specific business scenarios tests to have our work done.
Issue: Inflexibility when working with a remote grid server infrastructure. Selenium grid server hub and nodes configuration could take time to configure. Additionally, all test projects are going through a unique remote grid server infrastructure.
Our Solution: The Oshyn framework could be switched to different remote grid server farms by just changing a config file. If we need to run some tests through Selenium grid and others through Saucelabs, it’s completely possible. Additionally, the tests could be scheduled to run at a specific time of the day.
Issue: Inflexibility when working with different browser sizes. Extra code is required if we need to deal with different browser sizes and mobile devices.
Our Solution: Built in support to work with different browser sizes and mobile devices. This allows us to save time when writing tests because we just need to invoke a single method to change the size of viewport.
Our Solution: The Oshyn framework can be configured to detect these kinds of errors, making sure all our client scripts are correctly written.
Issue: One locator per control. It’s pretty common to find locators pointing out to controls that have frequent content changes. For these cases it’s useful to have two different locators: one to distinguish a change in the content and another to determine if the control itself exists in the DOM of the page.
Our Solution: The Oshyn framework includes the ability to use different locators for the same control. All of them are defined with XML files.
Issue: No patterns or best practices included. The Selenium API can be consumed from any application or website. This means it has no built in support for patterns or best practices to build our source code.
Our Solution: Built in support of Page Object Model (POM) pattern. You simply have to define the page classes and its related controls in order to start generating your first tests.
This Out Of The Box (OOTB) functionality of Oshyn's proprietary UI Testing Framework make it faster and more reliable for our customers to realize the benefits of Test Automation for their Sitecore websites. These features get rolled up into the Continuous Integration server, so they are executed on every build and nightly against production websites to ensure the site continues to function as expected over time, across releases.