The Future of Story Tests with Selenium WebDrivers and ISTA 2012

Damyan Petev / Wednesday, December 5, 2012

Test Automation: A Future with Selenium WebDrivers, ISTA 2012 conference presentationThis year we had the pleasure of being part of the second “Innovations in Software Test Automation (ISTA 2012)” conference! This year with even more companies joining for knowledge sharing, additional workshop/hands-on track and a lot more participants. ISTA is gathering a healthy range of quality engineers, software test automation experts and developers to the common goal of sharing new technologies and best practices in the fields of automation. This conference provides for a greater exposure of the software test automation role, which makes it a good place for some to choose career path, gain new insight( or share some of their own! ) and generally gain a better  understanding of just how diverse problems can be met and solved in the field. Our Principal Architect, Angel Todorov, who’s been recently focused on our Ignite UI jQuery controls gave an awesome presentation on Automated Web UI Testing… on Steroids! More on that later. The goodness spreading doesn’t have to be only once a year, right? Right. So the conference is also issuing a quarterly newsletter (you can sign up here). One of our talented Quality Engineers, Borislav Traikov,  has been providing some food for thought via article for the conference newsletter.

The Future of Story Tests with Selenium and WebDrivers

Selenium has been a recurring mention when it comes to Web Test automation – either directly, or a subtle-yet-preferred base for a framework, it comes up one way or another. And frankly I think that’s a good thing, as major companies having interest in the project simply means better support and contribution to it. And I’m definitely not the only one – taken from Borislav’s article:

Performing automated tests on web applications can be crucial to the success of a project, due to the fact that cross-browser support is a mine field for potential problems and defects. On the other hand, web applications are platform-independent (for the most part). Thus, they can be tested natively (with frameworks such as QUnit) in the browser, or by frameworks that utilize first-class languages (such as C#, Java, Python and so on, while this choice provides a wide window for automated testers to step in and start writing tests. So, if a web application testing framework is to be successful, it should satisfy these needs. Selenium has been doing great so far, providing a cross-browser API over multiple languages. While the Selenium API provided great DOM abstraction and traversal, it had its shortcomings – the biggest of which was its use of JavaScript sandboxing (Selenium v.1, also known as Selenium RemoteControl, used the JavaScript engine of the current browser as a way of interacting with it). In most cases that wouldn’t matter, but with more complicated web applications under test, interaction with JavaScript events, rather than emulation of real mouse clicks or keyboard interaction simply wasn’t enough. Also, the Selenium API was growing steadily with each release, and while that was awesome (grey areas were addressed and bug fixes were applied), one had to wait for a release or two to get the API method that they sorely needed (or extend the framework themselves – after all, Selenium is an open-source framework).

While Selenium was rising to fame among automated testers and gathering commercial support, an engineer at Google wanted something more: a test framework that would break free from the JS sandboxing and instead would natively speak to the browser. With so many different browsers, that was no small feat. Thus, the WebDriver project was born. With backing from Google, this automatically meant that Google Chrome (well-known for its distribution of stable nightly builds) and its little brother: the Android browser would be supported. This alone would open the door to a huge improvement in test automation, seeing as how the Android browser holds a solid 24% of the mobile OS market (during the time of writing of this article). However, the other runners-up in this “mobile browser war” – Safari and Opera – are still tough challenges for any cross-browser testing framework.

In 2008, the Selenium and WebDriver teams decided that it was time to join forces and to improve Selenium with the advantages of WebDriver: Selenium WebDriver. The transition from RemoteControl to WebDriver is still going strong alongside the continuous development of the WebDriver API – these facts raise both hopes and questions about the near and far future of test automation with Selenium.

There’s a ton of interesting info in there, pros and cons of the WebDriver and some thoughts on the (hopefully) bright future of test automation. It’s definitely worth checking out, so go ahead and read The Future of Story Tests with Selenium and WebDrivers!

Honorable mentions

That’s not all! There are more topics to spark your interest:

Software Localization … more than just using Google Translate, by Desislava Nikolova

Best Practices: How To Test Performance Of A New Product, by Grigor Svetoslavov

Automated Web UI Testing on Steroids:

Automated Web UI Testing on Steroids: Behavior-Driven Development, Headless Browser Environments, and Test Bed Generation.Behavior-Driven Development, Headless Browser Environments, and Test Bed Generation.

As I mentioned Angel Todorov presented some of the methods and innovations used right here at Infragistics. Yup, it’s basically info straight from source and it’s pretty interesting stuff as well. The presentation covers a number of limitations, problems and approaches to address them. It starts by giving an overview of some common frameworks and practices used to automate Web UIs, and lists their advantages and disadvantages. It continues by describing a unified framework for UI automation, involving a combination of tools, some of which come from relatively new concepts such as headless browser environments. The key goals? -  Faster test execution, more reliable test results, improving code reuse, and achieving greater productivity!

There are details on the cucumber-based framework we are using to describe scenarios and features in the Gherkin syntax and the tools to integrate that into the process. It’s a style that provides readability for the test cases so the stakeholders and managers can take part of the action. Again, something you should definitely not miss – you can follow the link above to read some more and there’s a downloadable version of the presentation deck. For those of you that can’t wait here’s a direct link to slides for the Automated Web UI Testing on Steroids presentation.


I’ll end this with something I’d like to say, but as you see I’ll have to just repeat:


That was ISTA 2012! You guys rock, thank you!

Embedded image permalink

And see you next year!