An automation framework is a way to organize your code in meaningful manner so that any person who is working with you can understand what each file contains.
Automation frameworks differ based on how you organize your code – it can be organized based on your data, so that any person who wants to use or edit data files such as an excel sheet can do so easily. These types of frameworks are known as data-driven frameworks.
Keyword-driven frameworks are those which can be written with keyword functions such as: Login, ClickButton, SearchList etc. These enable automation engineers to work within the framework easily, without ambiguity in function or code.
The combination of the above is called a Hybrid framework. There are some other frameworks which are named according to their usage such as Modular frameworks, structural frameworks etc.
Long story short, a framework is a way to organize your complex code logic in a more meaningful way to make life easier.
This can result in many advantages such as:
- Easily understandable code.
- Code that is easy to debug.
- Rapid development of code.
- Less error prone code.
Automation frameworks are developed during the initial stage of any automation project. But, as we know, the initial phase of automation will not contain all the final project features. These will be added to the framework incrementally, hence we will start with small steps known as Folder structures. These dictate where we are going to place our codes within the folder. The folders in this structure are given clear and meaningful names such as “Utilities”, “Core” and “Test Data”.
Once we have the folder structure in place, we can place the code files within those folders. The folder structures are common in any framework or automation testing tool.
The next step focuses on the “Reusability” of the code we write. Starting with the first iteration, the code should be written with the intention of future use. Ideally, the code can be reused by the team with few or no changes.
Similarly, the code should also be “Generic” meaning the code should be compatible with more than one application. Since you are investing a lot of time in your framework design and development, tomorrow your company can come up with a new plan and can ask you to automate application B using the process you used when automating application A. If you have written your framework specifically for application A, then you must re-write your code for Application B. Lesson of the story— try to avoid writing code specific to a particular application. Of course, there are cases where you must write code for a particular application. In these cases, try to isolate the application specific code in your framework and make it more visible so that anybody working in the framework can understand that it’s only relevant to that application and not common to the whole framework.
Code written for automation must contain clear comments that include the description of the code (which can include the actual functionality of the code) and a specified return type. The latter should be familiar to any programmer since automation test engineers are no different from programmers.
Above is a basic structure of how your framework should look, as every framework or design has its own structure, which can best understood by pictorial representation.
As you can see in the diagram, the framework has just 3 layers, but you can increase the layers of abstraction in such a way that it can have between 3 and 10 layers. But the number of layers depends on your needs and the complexity of your automation framework.
The theory of framework layering is this: The more layers of abstraction you create, the more efficient your framework will be.
This was just an introduction to automation frameworks but I hope you got a basic idea of what they are all about.
What is a test automation framework?
A test automation framework is a set of guidelines like coding standards, test-data handling, object repository treatment etc., which when followed during automation scripting, produce beneficial outcomes like increased code re-usability, higher portability, reduced script maintenance costs, etc.
These are just guidelines and not rules; they are not mandatory and you can still script without following them but you may miss out on the advantages of having a framework.
Ten steps for test automation framework methodology:
- Identify the scope of testing: Company oriented, Product oriented, Project Oriented, etc.
- Identify the needs of testing: identify types of testing e.g. FT, Web Services, etc. and applications / modules to be tested.
- Identify the requirements of testing: find out the nature of your requirements, identify types of actions for each requirement identify high priority requirements.
- Evaluate the test automation tool: evaluation checklist, identify the candidate tools available in the market, sample run, rate & select the tools, implementation, and training.
- Identify the actions to be automated: Actions, Validations, and requirements supported by the tool design of the test automation framework: framework guidelines, validations, actions involved, systems involved, tool extensibility support, customs messages, and UML documentation.
- Design of the input data bank: types of input files, categorization, and design of the file prototypes.
- Develop the automation framework: development of script based upon framework design, driver scripts, worker scripts, record / playback, screen / window / transaction, action / keyword & data driven.
- Population of input data bank: different types of data input, populate data from different data sources, manual input of data and parent – child data hierarchy.
- Configuration of the schedulers: Identify scheduler requirements and configure the schedulers.
