Record and playback features in test automation tools have a bad reputation. Why? When you purchase the automation tool it says on the tin “record and play back”. And for most tools this is exactly what they do. Yet many users seem to expect far more. Let’s be clear though, the tin does not say “record and play back with 4 man years of development which will deliver you a world class framework that will make you look like a god in the realm of software test automation”.
As users our expectations for this technology are set far to high. Most test automation tools have this feature and pretty much all of them implement this very well. When you look at the technology and the way it is implemented it works extremely well. It will record every mouse movement, every key stroke, screen shots and log absolutely everything the user does. Equally the tools are very capable when it comes to play back. They literally do playback everything exactly as they are designed to. The mechanism employed here is fundamentally very good.
Yet as testers we seem to expect far more. On playback, windows or your browser, will render an object differently and the playback grinds to a halt. It’s like you or me following a map in the desert. Every time we try to walk the same route looking at the map, someone moves the sand dunes. It’s not the fault of the map. No one told the map that the landscape had changed. It’s the same for your recorded script. No one told the script that the underlying application changed and that the names of the objects get modified every time it’s run.
This is the issue I have with the criticism record and play back technology attracts. It’s not the fault of the underlying features. It’s a damn good mechanism and does what it was designed to do very well. The problems lie both with the expectations of the end user and the fact that the landscape we’re trying to map changes frequently. So my argument is that the fault lies with the end user and environments which we try to use this clever technology on.
Without record and playback technology in test automation tools we’d have to start scripting from the scratch every time. This would make things far more difficult for us on two levels. Firstly our learning curve on these applications would be much steeper. No more record a scenario and then see how the applications scripting language constructs things. Secondly we’d spend ages constructing the initial scripts. Recording that first test automation path may only represent 10 or 20% of the final automation code but it’s still a big saving in time over having to write the script from scratch in the first place.
Whilst there is a strong argument that manufacturers have over sold this technology I don’t think we should loose sight of what it does give us. It gives us a capability that we can use to save ourselves time, effort and money. Just don’t expect it to build you a world class framework that will scale indefinitely as your requirements grow. Set your expectations reasonably because without record and play back in test automation tools we’d be far worse off.
