Here I am continuing with the Ministry of Testing 30 Days of Testing Tools challenge. No tool is more misunderstood that Record and Playback, so its no surprise that Simon Tomes decided to include a link to my talk on the subject on the Club when announcing this particular activity.

Day 5 – What tools do you think are underrated or misunderstood?

When I saw the topic for Day 5 of this challenge, the first thing that came to my head was Record and Playback. I have previously written and spoken about my support for Record and Playback tools in test automation, and I still stand by my comments. This is despite the fact that I’ve not actually worked with a test automation framework that included Record and Playback tools for a couple of years.

Record and Playback is a tool included in some automation frameworks that allows you to record actions to include in a test. The action is played back when you run the test. Its actually a bit of a misnomer as it doesn’t actually record your actions. Instead it automatically generates code which is run when the user ‘plays back’ the recording.

The problem with this misconception

Out of all my talks and blog posts, the ones focused on this Record and Playback appears to have been regarded as the most controversial. I’ve been accused of not being a good developer because of my support for Record and Playback. One person told me that I clearly needed more experience as Record and Playback will never develop useful automated tests. It is a real shame there are people like this. If someone finds a tool useful, then we shouldn’t ridicule them for using it or question their skills.

Some feedback was actually very constructive and helped continue the conversation (which is the desired outcome for any blog post or talk I create). I had an interesting discussion with someone about if Record and Playback actually made test automation development easier. He believed that it was easier to just write the code instead of using the Record and Playback tool to generate the code for you. He does raise an important point here, as not everyone will find Record and Playback tools useful. We shouldn’t force someone to use a tool if they do not see any value in it.

Why does this misunderstanding exist?

I believe the main misunderstanding of Record and Playback stems from the way people believe it should be used. Many believe that you can just hit record, perform the required actions for the test, hit save and a new test has been created. Unfortunately it is rarely as simple as this as the code will need some refactoring. Any accidental clicks have to be removed, locators need updating to make sure they work each time, timing issues need to be dealt with and variables will need replacing. In addition, if any change is made to the application then the test will need updating again.

Any novice programmers hoping to use Record and Playback to automatically write the tests for them will be disappointed. However, they may still find the tool useful to help them learn to code by analysing the generated code, understanding what it does, then rewriting it so it will work better when running the tests.

Personally I think that Record and Playback needs to be called something different. Since a large amount of refactoring is usually involved, a more accurate title would be Record and Refactor. Some believe that good developers will never use a tool that writes the code for them. However, with the amount of refactoring often required for the generated code, it could be argued that you still need to be a good programmer to be able to use Record and Playback effectively.

How should we be using Record and Playback?

I’ve mainly used Record and Playback as an initial code generator, refactoring the code after creating each recording to improve the future reliability of the test. I would create a recording for each step rather than contain entire tests in a single recording. This improved the tests maintainability as new steps could be inserted into the test, or existing steps updated or deleted. Individual steps could also be reused in other tests.

Sometimes I prefer writing the code from scratch, it depends entirely on the step I’m working on. Just because a tool is available doesn’t mean we have to be using it. Instead we should aim to do our job as efficiently as possible. We should not be ashamed of using (or not using) any available tool to help us achieve our goals.

Further Reading

I go into more detail about the benefits of Record and Playback feature in the following article:
Benefits of Record and Playback Features in Test Automation

In the following article I discuss how to refactor code generated from recorded code:
Adapting Recorded Test Cases to Improve Your Test Automation

Conference Talks

The Joy of Record and Playback in Test Automation
Link to recording from TestBash Manchester 2019 – Pro account required
Link to recording from TestCon Europe 2019

Ministry of Testing Club Discussion

Day 5 activity discussion – See what other other tools people think are underrated or misunderstood