A Recorded Framework

Record and playback has a negative stigma. Careful use though can result in something that is usable.

Maximizing reuse is the obvious choice in any framework. With reuse one minimizes the amount of effort required in maintaining the automated scripts. There are a few considerations when looking at a tool to achieve this:

• Does the tool support calling scripts from within a scripts?
• Does the tool support another means of calling a script?
• Can a script be saved as a function and called as a function?
• Does the tool support a global object map?
• Does the tool support associated libraries?

These various features reduce maintenance by facilitating reuse. The structure of the scripts needs some consideration.

• How to pass data?
• How to handle failure?
• What granularity should be used in setting up the scripts?

These considerations depend on the capabilities of the tool. The most useful options in dealing with this are to use more advanced frameworks which in general mean that scripts are coded rather than recorded.

Test Automation Frameworks

There is confusion over what a framework is. So what should one call a framework?

To me a framework is simply an implementation strategy. An idea that is applied to the whole test automation project. I've seen more focused definitions but they don't make much sense. My broad definition may open the door to the reviled record-and-playback, but it can be used as a test automation strategy (although with a lot of care) and so should be included.

The generally accepted primary framework types are:

• Data driven


• Keyword driven

There isn't anything fancy about these except the amount of code that needs to be written in order to get them to work. To keep things simple, I'll post separately on each of these types.