Selenium – The top five things I learned at the Selenium Conference
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.
Selenium RC is dead – 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.
Selenium is awesome/don't use selenium – 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 if
Christmastime 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!