The first time I was presented Selenium I had the wrong understanding of it.
For that purpose Selenium acts as a browser plugin that allows one to record his actions on the browser on a particular site and play them back later.
You can also finetune the generated scripts.
In the same time I was starting to think about acceptance testing and automation testing.
Until the Continuous Integration and Testing conference in London, I didn't realise there was a link between the two.
During that Open Space conference, there was a talk by a guy from Germany.
He was sharing his experience with Selenium for acceptance testing.
Obviously the product he was developing is a web application.
It means that most of features (or business value) are accessible from a web GUI.
This how it became really clear to me that Selenium can work in two way: in addition of the plugin mode for manual record/playback, there's a driven mode that allow a programmatic control of Selenium. Now we are getting closer to automation :-)
Before going that way, I'll dwell a bit more on the acceptance testing part of it.
The acceptance tests are the tests that prove the product owner/customer that the software is doing what he has specified. For a web applications, most of the business features are visible on a web interface. Even if for some reasons the business value is invisible (backend features of some sort) it's often possible to make it exposed on a web interface:
On an earlier project one of the requirement was that the system should process data within a ceration amount of time. We build a small web application to expose the cycle duration on a web interface. We used Nagios to monitor this value but we could easily imagine that this information can also be captured for acceptance tests.
Let's say that you've been asked to syndicate your data as RSS feeds. You can use Firefox as an RSS aggregator and test the feeds from there.
On another project the feature was to import a continuing feed of complex XML documents in a database. The team setup a smart logging and exposed import successes and failure on a web interface.
Now, we can go back to automation.
Selenium can be driven programmatically through a number of platform (java, python, ruby and perl). It uses a component called Selenium Remote Control which is a java server that run on the same platform where a web browser is available.
There's also a platform dependent API that sensd command to the Remote control using the language of choice.
In perl you can use a CPAN module called Test::WWW::Selenium.
The whole thing becomes really interesting when you combine that approach with the use of FIT (Framework for Integration Testing, which is more than a framework actually), but that's another story.