Top 5 things I learned at the 2013 Selenium Conference

Today was the first day of the Selenium Conference 2013 Boston. Overall, if I were to compare it to HP Discover, the Selenium Conference was much more technical, test tool-specific and laid back – no buzz word-speaking suits here. The top five things I took away from day one are:

• Selenium Builder – Sauce Labs's Jason Carr showed the new open source framework, Selenium Builder, which he said will be the eventual replacement for Selenium IDE. If you're currently developing record and playback automated scripts using Selenium IDE, stop now and check on Selenium Builder. With its clean, intuitive UI and improved script exporting to your favorite programming language feature it looks to be a big improvement on IDE. Also, users of GitHub will love Selenium Builder's GitHub plug-in that allows for seamless integrations.
• Dima Kovalenko from Groupon gave a presentation on tips for stabilizing Selenium builds. He covered several topics; the two I really liked were his tips for IE and Selenium Grid.
  • Dima showed some features for his Selenium-Grid-Extras project which provides an API that helps you to manage a Selenium Grid Node farm programmatically.
  • He also shared four Windows/IE-specific recommendations. The one that really caught my attention was his recommendation to first move the mouse outside IE to a specified position like 0,0. Supposedly, due to weird IE DOM behavior this will help increase IE script stability. (At first, this tip seemed odd, but after he explained it, I realized that it may in fact resolve some of the funky issues I've been seeing with our IE test runs.)
• David Burns from Mozilla offered a glimpse into what the future of Selenium automated mobile scripting might look like. He showed some of his new development work on a proposal for a WebDriver mobile API—basically being able to emulation gestures to Webdriver on mobile.
• SalesForce is insane — they have over 75,000 automated selenium tests! David Louvton and Amool Gupta presented what was basically a case study on how they evolved Salesforce's automation testing efforts into becoming more stable, maintainable and scalable using The Cloud.
• The coolest part of the conference was and is that all the sessions are available free on the Selenium Conference 2013 site! You should definitely check it out.

Tune in tomorrow for my thoughts on the Day Two sessions…

After an excellent first day at the Selenium Conference in Boston, I was excited about day two. I'm happy to report that the day two Selenium Sessions did not disappoint! Here are the top five things I learned on day two:

Facebook uses Selenium

Facebook is not only one of the biggest and coolest companies in the world, but they also use Selenium. Most development at Facebook is done using PHP and uses the PHP webdriver binding found on facebook's GitHub site https://github.com/facebook/php-webdriver.

At Facebook, there are no traditional QA tester roles. Developers are responsible for their code – from conception to production – forever, and they are responsible for testing and creating their own automated tests.

One of the interesting nuggets I learned from this presentation was that if one of their automated tests fails, a bug is automatically created and assigned to the developer of the code. If the test is not fixed in 24 hours, it is automatically deleted. The simple thinking behind this is that if someone doesn't care enough about the test to fix it quickly, then it must not be that important.

It was announced that now is the time for people who are still using Selenium Remote Control to begin migrating to webdriver. Webdriver is the future, while RC will be depreciated. Going forward, only emergency fixes will go into RC; no other development will occur.

This sounds like a Zen koan (a succinct paradoxical statement or question used as a meditation discipline for novices). Yes. Selenium is great and can handle many web browser automated tests, but like any GUI automation tool, it has the three GUI automation pitfalls: it's slow to run, hard to maintain, and hard to make reliable.

Browser UI automation should not be the only type of testing you are doing. Before using Selenium you should ask yourself why. Is there a better, faster test type that can be used?

Google's automation rule of thumb is: 70% should be unit tests, 20% should be service integration testing and only 10% should be full blown GUI automation. If you can test a feature without having to render a browser, you should automate that first. Funny, since this tip was offered by more than one of the main contributors to Selenium!

Selenium Three is coming December 2013!

As ifChristmastime is not exiting enough, the Selenium team is planning to roll out the newest version of Selenium sometime around December 2013. When this happens, RC will be officially depreciated.

Looking for more contributors to Selenium

I think it's easy to forget that Selenium is an open source tool and that most of the contributors to the Selenium project do so during their own time — and for free. And it was clear that some of the contributors who have been dedicating large chunks of time and effort to the project are getting burned out.

So what does that mean? It means everyone else – including me – needs to start stepping up to the plate. So find a way to start helping out. Whether it's helping to fix some of the existing bugs or writing some Selenium documentation.

In fact, if you go to Selenium's issue list you'll see certain bugs with the summary of “GettingInvolved” written. These are issues that have been identified as ones that would be easy to tackle for someone who is looking to begin contributing. So roll up your sleeves, fire up your MacBook and go for it!