1.2.4. Recorded Tests
Prev | 1.2. Comparison to other testing approaches | Next

### 1.2.4. Recorded Tests

Possibly the most popular approach to automated functional testing is macro recording, that is, recording a user’s actions for later playback. The appeal of this approach is the apparently quick success that can be seen: a test script can be quickly recorded and played back, giving the impression that automated testing is nothing more than recording a manual test.

However, this approach fails to meet the needs of large or long-term software projects for the following reasons:

- Test specification begins very late in the development cycle, as recording can only begin once the software is available.

- Since only the user action is recorded, checkpoints for verification of test results have to be inserted manually.

- Recorded tests can only test parts of the application which already work.

- There is also the danger that the implementation of the application will be tested, instead of the requirements.

- Recorded scripts are often very large and not particularly well-structured. Making changes at a later point is therefore difficult and requires programming skills, which further increases costs.

- Code generated by recording generally doesn’t conform to common software quality attributes such as reliability, stability, portability, maintainability, and usability.

In essence, a recorded script is not an automated test. It must be refactored to remove errors and redundancies, to make its component parts modular and reusable and to insert the intelligence of the manual tester to make the test robust. Once all this has been done, there is probably very little of the original recording left, and a great deal of development work has been done to refactor the script.