If we consider automation testing as a fine art then creating an automation Testing framework is like creating the base of the art. It should be decorated with precision.
It needs proper experience as well as deeper knowledge about the exact requirement. A well-created framework will speed up automation testing in every aspect. In another hand, some mistakes while creating the framework can cost a blunder for the tester in the future
- Example: Below is the structure of a hybrid framework
Let’s analyze those 10 common mistakes which we need to avoid while designing an automation framework :
1. Framework should be created based on the analysis of requirements:-
Many types of Automation frameworks are there which will satisfy different requirements.
- Behavior’s-Driven Development Testing Framework (BDD)
- Test-Driven Development Testing Framework (TDD)
- Hybrid Driven Testing Framework etc.
For example: If there is a need to satisfy Behavior’s-Driven Development then the framework should be BDD Framework.
- Usage of repetitive code should be ignored:-
The framework should follow the page-object model so that the number of repetitive codes can be minimized as well as the codes will be more portable for the implementation purpose.
- Naming Convention (for methods and classes) should not be random or meaningless: –
Always use naming conventions such as if anyone will read the method name then he or she can understand what functionalities are getting covered by that method. Similarly For the class Name naming should be meaningful.
- For example– all the methods related to Homepage will be written under this class, so the class name should be like this “ HomePage.java”
4. Do not hardcode any value in any method: –
It’s not good practice to hardcode values. Values should be passed through variables.
- Do not forget to maintain a UML or class diagram of the framework: –
Finding a simple class from a framework can be a huge task (as there are several packages) , if there is no class diagram or UML diagram. So, maintain a UML diagram or class diagram so that if any new member joins the team, they can easily understand the framework structure and use it with ease.
- Should not use implicit and explicit timeout duration hardcoded everywhere, this should come from a constant place like test util or from config. Properties: –
Because if we need to change the implicit and explicit time duration then it will be difficult to find out each line from several codes and change it. if it comes from the util class then easily the time duration can be changed without interrupting the code.
- Functionalities that are common should not be written anywhere, a common util package should have all the common functionalities: –
There are some common functionalities like taking screenshots, clicking a button, dragging and dropping functionality, selecting an element from a drop-down, mouse hovering on an element, etc. These functions should be written inside util class and by calling it we can use those functions anywhere.
- Do not forget to maintain a ReadMe file under the framework: –
For proper maintenance of the code with the framework, one should always go for the Readme File where you can write down
- which functionalities are getting covered by which test cases and
- if there is any bug related to any test case, here it can be noted down
- maintain tasks related to sprint with sprint number
- If any automation is in an impediment state, it should be noted down here
- Do not write the test data inside the method: –
Always use Data Provider for testing to send the test data, and if the number of data is huge then the data provider should read an excel sheet to get the test data, or feature file examples can be used to send test data for Cucumber BDD if the number of test data is less.
- Do not forget to add the functionality which will take a screenshot of every failed test case with a proper name: –
This functionality will help in debugging as well as execution report purposes. To enrich the framework it should be added.
Blog written by