Test Automation Framework

Lately, I have seen a trend where new test automaters do not know what a test automation framework is. I thought I'd enlighten everyone by sharing with you what it is and why you need to know what it is.

If you search for the term on Wikipedia, you come up with the following page and the following description of what a test automation frame work is:

http://en.wikipedia.org/wiki/Test_automation_framework

"A test automation framework is a set of assumptions, concepts and tools that provide support for automated software testing. The main advantage of such a framework is the low cost for maintenance. If there is change to any test case then only the test case file needs to be updated and the Driver Script and Startup script will remain the same. Ideally, there is no need to update the scripts in case of changes to the application."

This is a very high level way of looking at what it is. To be more precise, I've listed what I think need to be included with a test automation framework:

- Solution Design Document - how you came up with your chosen framework and its alternatives.
- Naming Standards Document - how you should name all your assets that exist under the current framework.
- Best Practices Guide  (Includes Coding standard) - how test assets should be designed, developed, built and implemented.
- User Guide - how a user of the test assets would go about using the stuff built.
- Implementation Guide (optional) - how you would setup a test automation engine that follows the current framework.

(Google the above if you don't know what they are)

Above are the only things you need for a test automation framework. Like any other framework, establishing a basic structure underlying a system, concept, or text is all you need to implementing a host of test automation assets. The test automation engine and its test assets are the end products of the initial framework that is setup.

The test automation framework and the test automation engine are two different things. Yet, to this day, I have still seen people referring to them interchangeably. Used loosely, I understand why but really, this should not be happening.

Why?

This is because for a proper implementation of a test automation framework, you need more than just a test automation engine but all the structures in place to ensure that the framework in place is of higher maturity.

Next, I'll talk about Test Automation Framework maturity.