Automation framework Architecture and how to build a simple framework in Real Time

In this post we will design our automation testing framework (which will be called as SPOMFramework). The design will look like the one shown

FRAMEWORK ARCHITECTURE

Well, automation framework is a way to organize your code in much meaningful manner, so that any person who is luckily working with you should understand what each file (Code file can be either a vbscript file) has.

Automation framework are different types based on the above organizing of your code, it can be organized based upon your data, so that any person who has the better idea to handle the data files such as excel sheet will even have the handle to control the code !!!, well we call these types of frameworks as data driven frameworks.

Similarly there are some frameworks which can be fully written with keywords of functions such as Login, ClickButton, SearchList etc to enable automation engineers to work within framework much easily without ambiguity of same function or code and use the keywords within a framework for performing some operations, we call these type of framework as Keyword driven framework.

The combination of both of the above is called as Hybrid framework and there are some other frameworks which are named according to their usage such as Modular frameworks, structural framework etc.

Long story short, framework is a way to organize your complex code logics in more meaningful way to make our life easier. This can bring many advantages such as

Easy to understand the code
Easy to debug the code
Rapid development of code
Less error prone code

Automation frameworks are developed during the initial stage of any automation to begin, but as we know initial phase of automation will not have all the features which we are going to put in to the framework to make it more great, hence we will start with baby steps of what is called as

Folder structures, they are more of where we are going to place each and every codes within the folder. The folders in the folders structure are given more meaningful names such as “Utilities” folder, “Core” folder, “Test Data” folder etc.

Now once we have the folder structures in place, we can place the code files within those folders.

The folder structures are common for any frameworks or any automation testing tools which we will use. Well, the next big thing is “Reusability” of any code we write, the code must be written in such a way that it can be reused. The code written once should be written with intention in mind that the code can be reused by the team without many any or no changes in the code.

Similarly the code should also be “Generic” means 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 automate application B while you have already in the process of automating application A. If you have written your framework more specific to Application A, then you will end up changing all your codes for Application B, hence try to avoid writing code more specific to a particular application. Well, there are cases where you can write very specifically for a particular application, in those cases, try to isolate the application specific stuffs in your framework and make it more visible, so that anybody working in framework can understand that its specific to application and not common to the whole framework.

Code written in automation must have clear comments in it, the comments should include the description of the code which can include the actual functionality of the code, if it has a return type then that too has to be specified, which is more normal as any programmers does, since automation test engineers are no different from a programmers, to me they are more than a programmers and a test engineer.

Wells what’s next, a basic structure of how your framework should look like, as every framework or design has its own structure, which can best understood by pictorial representation, I am also going to present you all via a pictorial representation of the framework structure as shown below.

As you could see in the diagram, the framework has got just 3 layers, but you can increase the layers of abstraction in such a way that it can have more than 3 layers to 10 layers. But it’s all depends upon your need and complexity of your automation framework.

The theory of framework layering is this, “The more you create the layers of abstraction, the more efficient your framework will be”.

Well this is the just an introduction about framework and I hope you got the basic idea of what a framework is 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 increase code re-usability, higher portability, reduced script maintenance cost etc. 
Importantly these are just guidelines and not rules; they are not mandatory and you can still scriptwithout following the guidelines. But we will miss out on the advantages of having a Framework.
Ten Steps for Test Automation Framework Methodology:
• Identification of the Scope of Testing: Company oriented, Product oriented, Project Oriented.
• Identification of the Needs of Testing: Identify Types of testing e.g. FT, Web Services etc.
  and application / modules to be tested.
• Identification of the Requirements of Testing: Find out the nature of requirements, 
  identify type of actions for each requirement & identify high priority requirements.
• Evaluation of the Test Automation Tool: Evaluation checklist, Identify the candidate tools available 
  in the market, Sample run, rate & select the tools, Implementation & Training
• Identification of the Actions to be automated: Actions, Validations & requirements supported by the Tool
• Design of the Test Automation Framework: Framework guidelines, validations, Actions Involved, Systems involved, Tool Extensibility Support, Customs messages & UML Documentation.
• Design of the Input Data Bank: Types of Input file. Input files – Categorization &    Design of file prototypes.
• Development of 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 & configure the   schedulers.