Tuesday, August 4, 2015

The age of Selenium

Selenium logo

Some quick notes from the 10th selenium meetup which took place at the IronSource offices.


My interests were primarily for testing websites and the spacial use case involving "analytics" setups. It turns out that both simple and complicated analytics setups require about six testing sessions. When working with large web sites analytics setup tend to get broken routinely. While custom alerts can help to detect large disasters, a automated testing tool is invaluable for tracking these type of failures early.

Oxygen IDE

English: Selenium IDE screenshot
The bleated Selenium IDE
 (Photo credit: Wikipedia)
The meetup started with an unscheduled  lightning talk by Nachum Dimer. This, for me, was the most productive talk, quite possibly because it was just 10 minutes and so had no fluf. It covered Oxygen Ide. Oxygen is a new Selenium framework and integrated development environment. Oxygen IDE allows recording on Internet Explorer, Firefox and Chrome. which is a significant improvement considering that Selenium IDE, which has not been has been updated for a long time, only supports recording in only. Oxygen supports recording in chrome and other browsers. Besides being an IDE is has command line interface as well as an API. Another advantage is that it records to JavaScript which means that the work flow can be 100% JavaScript and browser based. When a test fails it allows automated capture of the UI image for later inspection. The reports are in XML which is ideal for a CI system like Jenkins. Oxygen is also able to Interface with restful web services and with databases - allowing for a very complete testing solution in a single package. Needless to say I've started working with Oxygen!

Ruby based testing stack at MyHeritage

English: Watir logo
Watir
(Photo credit: Wikipedia)
In the second talk, Matan Goren and Yehuda Miller discussed how MyHeritage uses Watir, Ruby, Cucumber and other supporting technologies to automate end to end testing at scale, on a high volume website. Goren explained how QA automation engineers are an integral part of the Continuous Deployment process. His slide deck is online. The company has grown significantly in the last year and reached a limit for work with the semi automated tests. The technology used for testing is:

  • Ruby
  • WATIR
  • Cucumber 
  • The PageObject Gem
  • Grid Grouper (legacy grid component)
  • Selenium Grid and Grid Extras 
  • Jenkins for CI
Cucumber and cross section
Cucumber
 (Photo credit: Wikipedia)
The highlights are that WATIR and PageObject Gem which reduce setup and overhead of working directly with Selenium. These pay greater dividends when used as primitives in which are accessed in plain English using Cucumber which is the Behavior driven design tool of choice. Grids are then used to farm out tests on multiple browser simultaneously both for production and for staging and Jenkins does Continuous Integration. by using these tools they are able to get both QA people with background in manual to automate tests and to involve more developers in coding tests.

Robot Framework at IronSource

NXT Robot
The Robot Framework
 (Photo credit: Wikipedia)
The final talk was rather long and each speaker ended up repeating much of what the previous ones had covered. The speakers were Naphtali Gilead, Ben Weisblatt, and Ariel Levy from the InstallCore team at IronSource. They covered how they use the open source Robot Framework  and how it fits into IronSource's continuous integration life-cycle. Their technology stack is more python based. InstalCore is a monetized installer which generates revenue by offering people additional products. The testing involves complex advertising and installations. While the Robot Framework is a highly flexible test automation framework it relies on Python keywords. Its advantages are its mature libraries, informative reports, and ease of use for QA engineers. The talk will also touch on how it complements Selenium as a full end-to-end automation solution. The keywords allow layering the testing code into a number of levels. The top level with the high level keywords reads like English and the low level keywords are implemented in Python and are much closer to the actual SUT. All in all the Keyword solution seems very similar to Cucumber. One insight from this talk was that test should not be fragile but the developers also explained that they run all tests tests three times since their environment itself is rather fragile. This was a bit difficult for some people to get thier heads around. If you are interested in the Robot Framework have a look at this slide deck. And if you want more information on how it is used at IronSource here is a blog post covering this in more detail.

Conclusion

While some talks are invariably TLDR, the level of the Selenium Meetups are top notch and a great opportunity to learn from some of the top companies and to connect with the community since most of the selenium testing stacks are open source. Long live oxygen!