I've noticed recently that Selenium IDE has recently become real popular in companies with agile teams to automate their testing. Capture/playback testing is great to show-off your testing skills with a faster ROI, but it is definitely not productive for large scale testing (multiple projects, features, etc..). If you have a product that requires significant amount of testing, there is no way you can record and playback every scenario and then maintain them for future use. There will come a time, where you would need to programmatically interfere to make development of test cases against the acceptance criteria easier. A recent post from infoq about testing:
In the late afternoon there was a discussion around the role of record and playback tools such as the Selenium IDE. Lisa Crispin thinks that capture/playback tools “can be a great way to help learn a new tool, and also can be helpful in debugging test scripts or figuring out the right statements to use in a particular test. However, people shouldn’t get bogged down in only using capture/playback”. Jason Huggins, Selenium developer, explained that he is troubled by the general use of the Selenium IDE (really just a record/playback tool). It was originally intended as a “little 'trainer' airplane that jet pilots train on first. The pilots can learn a lot from the trainer, but eventually they have to move up to a real jet.”Don't get me wrong, w/ my limited experience of selenium, it has canned out to be a pretty good deal for testing, but one has to brush up on their scripting skills --- ruby, python or maybe even java to assist w/ selenium so as they can take full advantage of the tool and automate tests on a broader scale. Integrate that w/ a continuous integration system like hudson and you'll have yourself an environment self-sufficient for agile development.
Just my $0.03
