What is A Framework. A brief overview about the Automation Frameworks

What is A FW

A FW is a blueprint or a set of guidelines to organize the code. It tells the User of the FW things like:

1. Where to keep test cases.
2. Where to keep logs and reports
3. Where to keep and how to access locators.
4. How to control execution flow.
5. How to write test cases.
6. How to Configure

Etc

Types of FW:

There are many types of framework. For example:

1. Keyword Driven FW
2. Data Driven FW
3. Hybrid FW
4. Modular FW
5. Function Driven FW
6. Behavioural Framework

Etc

Out of these mainly KW driven, Data Driven and Hybrid Driven is widely discussed.

Types of FW is nothing but the concepts and list of guidelines.

Their actual implementation may vary from Project to Project or tools to tools.

They are independent of Tools. So for example, I can create a KW driven FW using QTP, UFT or Java-Selenium or any other tool as well.

KW Driven FW: A KW driven FW is a FW which is driven by Keywords created by the architect of the FW. They are usually Application specific plain english Business words, which will make sense to the actual user. For example, “LoginInToTheApp” is a keyword. Anyone can use it to login in to the application. They would not need to know the exact logic of it neither they need to write any code in order to login in to the application.

When a KW driven FW is created, first whole application is analyzed and common functionalities of the application is identified. Later code is written to make usable components of those functionalities.

Once that is done, another layer/wrapper is written over the code to provide access to those components from outside i.e. from an Excel file.

So actual test Case Writing happens in Excel file and not in any coding environment.

This is advantageous for FW users. Since, no coding efforts are required, any one from BA to Manual Testers can go ahead and create new Test Cases and contribute to automation efforts.

Disadvantage: Takes more time to create and has higher degree of rigidity.

Data Driven FW:

A data Driven FW is a Framework which is being driven by Data.

This type of approach is usually taken where data is the driving factor. For example in cases where Functionality of the application is same but data is changing. Best example is calculator application. In calculator application, its functionalities are constant like +,-,/ and*  but it has to be tested with Multiple data sets.

DataProvider in TestNG supports this Data Driven approach. For each Data Set in Data Provider same Test can be Executed.

So if you are using TestNG DataProvider in your FW, you can say that I am using Hybrid FW with Data Driven features in the form of TestNG Data Provider.

But most importantly, any FW which is using Excel file or DB to pull data and use them in the script can not be called as Data Driven.

A FW can only be called as Data Driven where multiple data sets are being used for limited functionality. Another Example: register 1000 users in the application.

Hybrid FW: Mix of everything is a Hybrid FW. Mostly nearly all the FWs are Hybrid FW which uses different approaches like Data Driven, KW Driven, Modular approach (Creating reusable components) etc

Components of FW:

There are in general 7 components of framework.

1. Driver: This component drives the FW. What is to be executed, in what sequence, with what parameters, prerequisite steps, configuration steps, path set ups etc
2. Config: Configurable data like paths, urls, username and passwords, data set up, DB connection string set up etc
3. Logs: Log level logs to log each and every step of the FW
4. Reports: High Level logs, plain english on what test case did and meaning full english results which would make sense to everyone viz-a-viz Client, BA, PM, manual tester etc
5. Page Locators/Objects: Storing locators of the application. Can be any valid document, like properties file, text file, CSV, excel file, DB, java file with page object model etc
6. Test Case Script: Actual test case steps to be written here.
7. Data: Any data fetching requirements from outside of the script. Like fetching content kept in excel file or fetching data from a Database and use that data in the test case.

There are multiple ways to implement above components. A typical example to  implemented could be as below:

Driver: Test NG

Config: Properties file or excel file

Logs: TestNG logs or Log4j.jar for advanced logging

Reports: TestNG HTML report or Extent Report.jar

Locators: Page object model using page factory

Test Case Script: TestNG class files.

Data: Excel, Txt, CSV files or Database, TestNZ XML

Components are not restricted to be only 7. One can merge two components in to one. For example: Logs and Reports can be implemented as single component where FW will have only one file to show logs and reports and could implement filtering mechanism to segregate high level logs with low level logs.

Reason we divide a frame work in component is to have a logical structuring of the code where each code-component has a logical division and is separated from each other. Why? So that code become more manageable and more understandable. People will clearly know what’s kept where and could scale the code if required.

It is imperative to segregate and structure your components to satisfy general coding principles like Scalability, Manageability, Modularity, Reusability, Robustness, Abstraction etc

The worst example is where everything is kept in a single java class file. Something like below.

Bad Example of a FW: Below Script has these flaws:

1. Using public static void main to drive test case. Can not control what needs to executed. Driver component which takes care of execution flow and what is to be executed and what not is not present.
2. Configuration related info is kept in the script itself at line 15.
3. Configuration URLs which is subject to change based on different environments in the real project. At line 22 url is hard coded.
4. Page Locators are kept in the same file at line 26,27 and 28
5. No log and and report provision is present

So in a nutshell, we have a single file where driver, config, page locators and test case steps all are merged.

It is a good way to start learning Java with selenium perhaps but a classic example of bad design; nothing can be worse than this.

This will make your code unmanageable when you have lots of test cases, probably to the tune of 100s of test cases.