I came across this link while searching for reference material to troubleshoot an issue in my Selenium tests:
The first 3 sections on this page ("Where to start?", "What are the issues", and "Main problems") are pure gold.
I don't know if we want to continue exploring Selenium and make automated browser testing. If we do, here are some ideas to consider:
- For any application which is a candidate for browser test automation, we should define smoke tests and "money path" tests early and keep them separate from the broader test suites. Only smoke tests and money path tests should be considered for acceptance testing.
- When deciding what tests to write, we should not aim for completeness (e.g. write tests for every feature) but for value (e.g. write tests for features whose failures would result in a significant negative impact to customers).
- We should limit our use of Selenese to basic testing such as smoke tests. More sophisticated browser tests should be written in a full programming language using either Selenium RC (Selenium 1) or the WebDriver API (Selenium 2).
- Developers should assign meaningful IDs to important HTML input and content elements so that automated tests can locate them more easily.
The discussion of continuous integration (CI) and Selenium is also valuable as examples of testing infrastructures. CI systems like Hudson/Jenkins are nice, but we could roll our own if we wanted to. However I do think it's important to have the CI system and the Web application under test on separate servers. Cloud hosting makes a lot of sense for CI systems that are only needed a few hours per week, so Cloudbees' DEV@cloud may be a nice fit here.
(repost from the mind of Daemonite, Dennis "Boomfish" Clark)
 Selenese is the HTML format used by Selenium core and the default output format of the Selenium IDE extension for Firefox.