Do you want to hear a story about overcoming obstacles and achieving seemingly unattainable goals at a massive scale? Well, we have one to tell - it’s a true story, and like all good stories, teaches us some valuable lessons. We have gone through the ups and downs of this tale and come out better and smarter. We would love to share those experiences and learning with everyone.

The story starts with a mission...automate 5000 hours of manual tests for our enterprise product. Like many other product based companies, we had one big monolithic application to test. The mission was to be accomplished with the resources available - no new magical dream team, we had to work with the resources we had - QA analysts with no technical background, a very small automation team, and a huge offshore manual testing group. Go figure! There was another twist - we had to accomplish our mission without dropping the current level of support for testing our enterprise application, including regression and new feature tests. Doesn't it all sound very familiar?

This presentation will cover all aspects of our journey from the beginning to the end. We went through a lot of ups and down, and every single decision we made taught us a great deal. It is those experiences that we want to share with everyone.

• We created a tool that wrapped the Selenium API in order to make it easy for non developers to write tests. The tests were written in a Domain Specific Language that made Selenium API calls with some application specific logic added in.
• We needed to build our own execution framework to support our growing automated test base. The framework offered many customized features and was able to sustain 60,000 hours of tests running every single day.
• We wrote our own best practices and worked closely with the QA team to make sure everyone wrote high quality tests.
• The results from the tests needed to be displayed in a way that made sense. We created several different dashboards for that purpose and had many different views of the test suite performance, including a heat map to highlight problem areas.
• Elasticsearch and Kibana were instrumental in helping us parse through the massive volume of test results and make sense of them, giving us metrics in different forms.
• Daily environment setup for this execution was also massive - 100 or so slaves and several SUTs for every codeline, with support for 3 codelines meant that we needed a big lab setup.

We successfully completed the mission of automating the manual test behemoth and gained a rich understanding of test automation at scale along the way.

The Page Object Model is awesome, but you can make it even better with Dependency Injection.  I'll show you how to get started and some benefits of using Spring IOC in your Page Objects.  Though the concepts of this talk can be extended to any language, the examples will be shown in Java.

Selenium made test automation easier and affordable for many software development teams, but it had many limitations.  It was limited to DOM manipulation in the browser, it depended on explicit waits.  

Webdriver helped overcome some of these deficiencies and took Selenium to the next level.  Other extensions like Appium have enabled us to use the familiar Selenium API for testing mobile apps.  Proprietary frameworks allow you to integrate Selenium with native extensions and ALM tools.  But a new category of apps is coming with responsive UIs, rich client side Javascript frameworks, touch screens (with pinch/zoom, swipe, rotation, etc) and interact with native device features (such as GPS, accelerometer, local storage) and apps are becoming a collection of interactive services.  

Is Selenium becoming outdated?  What can we do to keep up with these new interfaces and architectures?

In this talk, we'll discuss some of the challenges and limitations facing testers using Selenium with this new generation of apps.  We'll cover some of the solutions people are using today, and propose a new way to address these issues and others going forward.

Writing selenium tests has an inherent problem in which we can only automate what we know the steps for. It is primarily used for regression and can scale very quickly. We generally optimize regression for sprint's relevant features or have smoke tests to get quicker feedback. In addition negative testing is very expensive to write. This entire process is very manual and the maintenance of tests become more costly than the actual writing of tests. 

We can change this. By using genetic algorithm and cucumber steps we can create new feature files to discover where in the application may be be problematic. The goal of each individual would be to find the most defect. The two individuals that find the most defects then create children that follows the sequences of how new individuals are form through genetic algorithms. They will breed the next generation of testers which will focus on problematic areas. 

Let's find out when and if this strategy can be deemed effectively. 

Page-Object pattern is very commonly used when implementing Automation frameworks. However, as the scale of the framework grows, there is a limitation on how much reusability really happens. It inherently becomes very difficult to separate the test intent from the business domain.

Learn more about this problem, and the solution (by means of real-project examples) - Business Layer - Page - Object pattern, which has helped me keep my code DRY.