Selenium IDE is a free Firefox add-on that is used for automated website testing. One can record their mouse and keyboard inputs and create a 'test case'. Further customizion (i.e. confirming a phrase appears) can be done using Selenium or a text editor. One can then play back their test in Firefox and Selenium IDE will flag any errors or mismatches to the test case. Mostly I've used it to test Plone sites and bulletin boards. It's a brilliant tool for any development team.

Some of its best uses:

• Testing any functionality that could become broken at any given time during development.
• Automating repetitive tasks (like testing a registration form).
• Populating a site with content (to see how the skin behaves with long titles or to produce mass content to search).

As a non-programmer, I spent many hours looking for new ways to get Selenium to work for me, but in reality the answers are usually much simpler. Either it couldn't be done (storing a variable in one test case to reuse in a later test case) or the answer was simply to copy and paste and making a tiny change or two.

I found the earlier versions of Selenium IDE painful to use, but the current version has an excellent test runner, where you can run, stop, restart and edit tests, right in the Selenium window. When a new site is being built and skinned, the links, functions, and field labels can change often. The site needs to be tested continuously to catch any problems, before they are repeated elsewhere in the site.

As a result of these small but frequent changes, the Selenium test cases need to be updated frequently. I have found that when a test case fails, it is more likely to do with the test case being out of date, rather than the software being broken. This where having the ability to make a quick change to a test case in the Selenium window (without dipping out to the text editor) is very handy.

Just be sure to save anytime you make a change, either in the test runner or in the text editor. In the past, I've overwritten tests by making edits in two places.... [sigh].

My other tips:

• Give each test suite and test case a distinct and descriptive name.
• Break large test case into smaller test cases.
• Reuse test cases as much as possible - and store them in folder called 'shared' or similar.
• Number each step in a long test suite by numbering the test case titles (that are linked to the test cases) in the test suite file.
• Show your test suite to colleagues. Can they tell you what's being tested? Does the order make sense? Could the steps be clearer?

I think it's a great tool.