How to get started with Selenium: A Brief Overview
So you want to automate browser-driven tests, and you're not sure where to get started. You've heard of this "Selenium" thing, and you think it's what you want, but you can't be sure. Fret not! Here's a quick rundown of what you're looking at and how to get going. This is mostly adapted from two sources: the official documentation and my blog post on the subject from a short while ago.
Selenium IDE, Selenium RC, and Selenium Webdriver
There are three products with the name "Selenium". You can safely disregard the old Selenium RC product if you're just getting started, as it has been superseded by the new "Selenium Webdriver" product. That leaves Webdriver and Selenium IDE.
Selenium IDE is a firefox plugin that records simple automation tasks in the browser and saves them as XML so they can be played back. It is great for one-off tasks like recording the steps to repeat a bug report, but it produces output that is difficult to maintain in the long run, so you don't want to use it as the only tool for a large automation project like a full regression suite.
WebDriver, on the other hand, has two components: a client and a server. These can be bundled together if you're always going to execute your tasks on the same machine the code is running on, or you can use RemoteWebDriver to set up a dedicated machine for test execution separately from the machine used for code execution. In practice, this can be very useful if you want to, say, run the tests in a VM so you don't have browser windows popping up and closing all over your desktop while you're trying to debug something, so I always use RemoteWebDriver and just start a local instance of the server if I'm only running from one machine. But you can do as you please.
What language do I use?
So you've decided to use Webdriver, rather than Selenium IDE. Good for you! Now you have to decide what language you want to automate your tests in.
I have good news here too: ultimately, it doesn't matter. Pick a language that fits the tooling around your process, or, barring that, a language that you're personally comfortable in. Many people use the C#.net bindings or the Java bindings, but many more use python bindings. The libraries are the same across all bindings; the only thing that changes is the exact syntax of calling methods.
What do I automate?
Webdriver is very good at driving browsers, but it's still an unfortunate fact that GUI-based automation is slow and fragile compared to headless automation. Wherever possible, try to automate at a lower level, for example, a unit test or an integration test. This will provide much more stable, rapid tests.
That said, there is of course value in automating against a GUI. You should automate functional tests that are stable and provide value to your organization. Ultimately, only you (and your team) can decide what's worth automating. I suggest starting with simpler test cases so you can get a feel for how much work it takes to automate a script.
How do I structure my project?
My first functional test frameworks were for desktop and ATM software; I’d never heard of the PageObject concept, but I learned by example how much easier the tests were to read if you had a detailed framework. This also allows for separation of concerns with regards to staff: let those who are good at programming work on the framework, and those who have a good eye for test cases work on the test code itself by calling framework methods. The framework should contain everything needed to interact with the software under test, packaged up in clear, easily read methods like mainWindow.openHelp() or fileDialog.chooseFile(filename). Your test author shouldn’t have to know about things like button names or window handles or xpath locators in order to write a test; they should use something very close to human language, so it’s easy to verify that the automated test matches the manual test case.
In Webdriver, this is accomplished by using PageObjects. In essence, a PageObject is a class that represents a single page or portion of a page in your web application, akin to a class representing a screen or a dialog in desktop automation. There is a PageFactory class that can automatically create elements in your PageObject on the fly when they are required based on annotations; I suggest reading through the documentation, because this is a really neat little time-saver for creating your framework. I also like to create a helper method that will take in a url and return the PageObject that that URL represents, therefore allowing the test to figure out when it’s ended up on the wrong page by mistake.
What information do I need about the application?
The good news is you probably don't need a developer handy to figure out how to interact with the page! The bad news is you'll become intimately familiar with css selectors, xpath, and the structure of the DOM. If you're not very web-savvy, you may want to partner with a developer to help figure out what selectors you can use to get to elements. If you use jQuery, you can often test out your css selectors by passing them to the jQuery object and seeing if any elements are returned.
Where can I find more information when I get stuck?
You can always search this site and StackOverflow for questions (or ask one if the information is not already covered), but you'll also want to familiarize yourself really well with the documentation. There are also many books on the subject (such as this one) if you learn better from books, and you can find online web courses (like this one) if you learn better that way. Ultimately, test automation is one of those subjects in which you'll always be learning new tricks, and every project will build on the successes and failures of the previous one. Good luck!