Google Testing Blog: Selenium's Inventor

Selenium's Inventor

水曜日, 9月 19, 2007

Posted by Patrick Copeland, Test Engineering Director

We thought you might be interested in some articles from our internal monthly testing newsletter called CODE GREEN...

Many projects at Google have started using or are considering using Selenium. We recently interviewed Noogler (new people to Google) Jason Huggins, who is the creator and developer of Selenium, to learn about how it all started and where it's going. [Side note: Even before his first day at the Googleplex, Jason showed an amazing dedication to Google. After leaving Chicago with the big moving truck, he and his family had to stop after just a few hours because of an ice storm. Cars sliding off the road left and right. Further along, in Kansas, one of his kids caught pneumonia. His family stayed in the local hospital while Jason drove on. Heading west, there was a big snow storm in Colorado, which he wanted to avoid. He drove further south and ended up in a rare (but really real) dust storm over the Border States. He promised us some great video footage of his drive through tumbleweeds. He finally arrived and has settled in and is looking forward to calmer times in the Bay Area. After that trip, he isn't even worried about earthquakes, fires, mud slides, or traffic on the 101.]Couple of GTAC Videos with Jason: SeleniumRC, Selenium vs WebDriver
CG: Why did you invent Selenium? What was the motivation?
Huggins: Selenium was extracted from a web-based (Python + Plone!) time-and-expense (T&E) application my team and I were building for my previous employer. One of the mandates for the new T&E app was that it needed to be "fast, fast, fast." The legacy application was a client-server Lotus Notes application and wasn't scalable to the current number of offices and employees at the time. To live up to the "fast, fast, fast" design goal, we tried to improve and speed up the user experience as much as possible. For example, expense reports can get pretty long for people who travel a lot. No matter how many default rows we put in a blank expense form, people often needed to add more rows of expense items to their reports. So we added an "Add row" button to the expense report form. To make this "fast, fast, fast," I decided to use a button that triggered JavaScript to dynamically add one blank row to the form. At the time (Spring 2004), however, JavaScript was considered buggy and evil by most web developers, so I caught a lot of flak for not going with the classic approach of POSTing the form and triggering a complete page refresh with the current form data, plus one blank row.Going down the road of using JavaScript had consequences. For one, we had a really, really difficult time testing that little "Add row" button. And sadly, it broke often. One week "Add row" would be working in Mozilla (Firefox was pre-1.0), but broken in Internet Explorer. And of course, nothing was working in Safari since few developers were allowed to have Macs. ;-) The following week, we'd open a bug saying "'Add row' is broken in IE!!" The developer assigned to the issue would fix and test it in IE, but not test for regressions in Mozilla. So, "Add row" would now be broken in Mozilla, and I'd have to open a ticket saying "'Add row' is now broken in Mozilla!!!". Unlike most other corporate IT shops, we didn't have the luxury of telling all employees to use a single browser, and developers didn't want to manually test every feature in all supported browsers every time. Also, we had a very tiny budget and commercial testing tools were -- and still are -- ridiculously over-priced on a per-seat basis. The T&E project was done the "Agile Way" -- every developer does testing -- so shelling out thousands of dollars per developer for a testing tool wasn't going to happen. Never mind the fact that there were no commercial tools that did what we needed anyway!After many months of trial and error and various code workarounds, I came to the conclusion I needed a testing tool that would let me functional-test JavaScript-enhanced web user interfaces (aka "DHTML" or now "Ajax"). More specifically, I needed to test the browser UIs: Internet Explorer, Mozilla Firefox, and Safari. There were no commercial apps at the time that could do this, and the only open source option was JsUnit, which was more focused on unit testing pure JavaScript functions, rather than being a higher-level black-box/smoke-test walk through a web app. So we needed to write our own tool. Our first attempt was a Mozilla extension called "driftwood" (never released), coded by Andrew McCormick, another co-worker of mine at the time. It did make testing the "Add row" button possible, but since it was Mozilla-only, it wasn't what we needed for testing in all browsers. Paul Gross and I started over, and I started to educate myself on functional testing tools and techniques and stumbled upon Ward Cunningham's Framework for Integrated Testing (FIT). I originally set out to implement "FIT for JavaScript," but quickly realized we were drifting away from the FIT API, so Selenium became its own thing.CG: Why does the world need another test tool?
Huggins: At the time I created Selenium, had there been another testing tool that could test JavaScript UI features in all browsers on all platforms, believe me, I would have saved lots of time *not* writing my own tool.CG: What's special about it?
Huggins: Well, maybe the right question is "What's “lucky” about it? Selenium was created in a time when JavaScript was considered "bad" and generally avoided by most professional web developers. Then Google Maps hit the scene a year later, the term "Ajax" was coined, and BOOM! Overnight, JavaScript became "good." Also, Firefox started stealing market share from IE. The combination of needing to test 1) JavaScript features 2) in several browsers (not just IE) was a "right place, right time" moment for Selenium.CG: When did you realize that Selenium was a big deal? What was the tipping point?
Huggins: When I started being asked to give presentations or write about Selenium by people I didn't know. The tipping point for Selenium technically relied on two things: 1) the Selenium IDE for Firefox, written by Shinya Kasatani, which made installation and the first-hour experience tons better for new users. And 2), Selenium Remote Control (RC) created by Paul Hammant, and extended by Dan Fabulich, Nelson Sproul, and Patrick Lightbody, which let developers write their tests in Java, C#, Perl, Python, or Ruby, and not have to write all their tests in the original FIT-like HTML tables. Socially, if Google Maps or Gmail never existed and thus the whole Ajax gold rush, I wonder if JavaScript would still be considered "bad," with a similar "why bother?" attitude to testing it. CG: Have you discovered any interesting teams using Selenium in ways you'd never intended?
Huggins: At my previous company, I did see some developers write Selenium scripts to create their time and expense reports for them from YAML or XLS files. Since we hadn't exposed a back-end API, automating the browser for data entry was the next best thing. It was never designed for this purpose, but I started (ab)using it as coded bug reports. Asking users for steps on how to reproduce a bug naturally lends itself to looking like a Selenium test for that bug. Also, I've used the Selenium IDE Firefox plug-in to enter NBC's "Deal or No Deal" contest on their website from home, but I stopped doing that when I read in the fine print that the use of automation tools to enter their contest was grounds for disqualification. CG: What advice do you have to offer Google groups interested in Selenium?
Huggins: Well, one of the biggest drawbacks with user interface testing tools is that they're slow for various reasons. One way to bring the test run times down is to run them in parallel on a grid of servers, instead of sequentially. Of course, that isn't news to your average Googler. Engineers would be more likely to run automated browser UI tests if they could run 1000 tests in 1 minute total time on 1000 machines instead of 1000 tests in 1000 minutes on 1 machine. Sadly, though, most projects allocate only one machine, maybe two, to browser testing. I'm really excited to come to Google with the resources, the corporate interest, and the internal client base to make a large scale Selenium UI test farm possible. Eventually, I’d like to take Selenium in some new directions that we’ll talk about in later blog posts. But I'm getting ahead of myself. I have to survive Noogler training first.

22 件のコメント :

Benji2007年10月12日 9:59:00 GMT-7
I just have to say, thank you Jason. Selenium is an awesome tool and I really love it. I can't wait to see what comes of it now that you can harness the power and resources of Google. Keep up the good work.
返信削除
返信
匿名2008年6月21日 14:25:00 GMT-7
Hi Jason,

What benefits would you say Selenium has over Firewatir\Watir?
返信削除
返信
hugs2008年6月22日 8:54:00 GMT-7
Regarding Firewatir\Watir vs Selenium -- Selenium supports more languages (Ruby, Perl, Python, Java, C#, PHP, and a FIT-inspired HTML syntax for simple cases) while Firewatir\Watir only supports Ruby.

Some people prefer Watir's object oriented API style over Selenium's functional/procedural style. Selenium's API feels a bit more simple for simple cases. Some people (even I!) would argue that Watir's API is more elegant and polished than Selenium's. But I think this is a matter of preference, and not a critical difference in either case.

API example:
Watir:
browser.button(:id,'submit').click
Selenium:
browser.click('id=submit')

Also, Selenium's IDE for Firefox is very simple to use for newcomers, while Selenium RC and Grid "scales up" and provides more sophisticated features to parallelize test runs over many machines.

Traditionally, Watir has been an IE-only tool, but that is changing with better FireWatir integration. Meanwhile, Selenium has had better support for Firefox, but lacked some of Watir's features for testing IE. Over time, I expect the cross-browser differences between Selenium and Watir to converge capability-wise. But at the moment, Watir is a better tool for IE, and Selenium is a better tool for Firefox. Both tools have many "opportunities for improvement" for testing Safari.
返信削除
返信
匿名2008年7月30日 10:19:00 GMT-7
As your response was in the public domain, I posted on the Watir and Agile Testing group (I hope you don't mind). There has been some discussion. Charley Baker has responded to your post in a blog. You may find it of interest.
http://charleybakersblog.blogspot.com/
返信削除
返信
hugs2008年7月30日 11:42:00 GMT-7
agiletester, don't mind at all. :-) For the lazy, do you have a direct link to the related Watir and Agile Testing group threads?
返信削除
返信
Praveen2008年8月23日 2:13:00 GMT-7
Hi jason,

Your Selenium is an awesome tool and I really love it. Can you please provide me some documentation on how to use Selenium testing tool for testing and Web Application as i am new to it.
返信削除
返信
匿名2008年9月1日 21:09:00 GMT-7
Has Selenium been the primary tool for testing the new Chrome browser?

What are the plans for bringing Selenium and WebDriver closer together?

Thanks
返信削除
返信
Tushar Murudkar2008年9月28日 2:16:00 GMT-7
When will Selenium support java applets? Currently is there any hack to test java applets from Selenium ?
返信削除
返信
匿名2008年9月30日 14:30:00 GMT-7
tushar murudkar: could you not use JavaScript to talk to public Java methods in the applet?
返信削除
返信
hugs2008年9月30日 16:17:00 GMT-7
This is probably not the best place to answer the question of how Selenium can test Java applets. (Selenium forms at openqa.org would be better.) However, the short answer is: it's up to the applet author to make the applet testable. Remember, Selenium is written in JavaScript running in the browser. The applet author would need to expose methods in the applet to be callable by JavaScript. Once, exposed, Selenium would then be able to call those methods and test it. Search for "JavaScript-to-Java [bridge|communication]" for more information.
返信削除
返信
hugs2008年9月30日 16:21:00 GMT-7
Agiletester, regarding Selenium/WebDriver plans-- Simon Stewart has done a fantastic job improving WebDriver and implementing a compatibility API implementing the Selenium API. The effort could use more help, though... If you'd like to volunteer, the WebDriver and Selenium projects would truly appreciate it! :-)

Regarding Selenium and Chrome, my NDA with Google prevents me from saying anything really interesting about it. :-)
返信削除
返信
Kunal2009年9月26日 16:45:00 GMT-7
Hi All,
Iam looking for a Selenium white box tester for a fulltime position in Sunnyale CA.
If any interested and have refrences, please help me to find the right candidate.

Thanks
Kunal
Kunal@cbsinfosys.com
返信削除
返信
Guru2010年3月7日 7:54:00 GMT-8
Hi! Jason...

Its indeed a great work of urs that made things very very easier..

Thanks man... You did it!
返信削除
返信
Jitin Kulshrestha2010年5月1日 23:55:00 GMT-7
Selenium is too good. It is amazing when used with javascript.

http://new-trends-software-testing.blogspot.com/
返信削除
返信
Kiran2010年9月4日 19:40:00 GMT-7
Excellent and Amazing tool.
返信削除
返信
Unknown2010年10月10日 9:17:00 GMT-7
I've been using Selenium happily for 4 years along with Jameleon. Being a true believer of Open Source Tools, I just prepared an article "Web application data-driven test automation for non-believers" at http://tekselenium.com/wpautomationstrategies.html

Ayhan Tek
返信削除
返信
Isfar2011年7月7日 10:32:00 GMT-7
I know I am bit late to this blog, but I was not able to control myself from commenting that 'This is the most fantastic job' Thanks.
返信削除
返信
Unknown2013年12月2日 4:21:00 GMT-8

Appreciation for nice Update, I found something new and folks can get useful information about selenium Online Training
返信削除
返信
Kaushal2016年7月30日 0:55:00 GMT-7
Great tools
返信削除
返信
Avinash Mishra2017年8月5日 6:16:00 GMT-7
I am using Selenium since 2015. It has changed my Testing lifestyle. I must say it is the great invention in QA industry.

Thanks to Jason and Team. :)

Cheers (Y)
返信削除
返信