To design an effective automation framework which helps reduce the release cycle and accelerate market release, application-independent test automation frameworks become a necessity. Components such as function libraries, test data sources object details and various other reusable modules act as building blocks. These blocks are assembled to create a business process framework and provides basis for test automation and also simplifies the automation efforts.
The illustration below explains the situation where Page Object Model acts as a backbone.
The following components are included in Application under Test (AUT):
1. Reusable Library
Reusable library consist of common functions that can be reused application wide. It also acts as a repository for the all the objects and elements of AUT.
Example: Login page is a class file that contains base functions and their objects. As you can see Page elements and associated functions are defined in one single class. These functions will be exposed to the verification layer of the AUT where the tests use them.
2. Shared Resources
It contains the collection of utilities and resources that are shared in the entire application. It may be like handling different types of browsers, managing different parser utilities which in turn can be used to fetch data from different file formats and make them consistent for use in AUT, or defining preconditions that should be called before test verification begins.
3. Test Scripts
This section is the Verification layer of AUT. It contains Test scripts which performs the task for carrying out the verification of AUT. They define the entire flow for verifying the specific feature of AUT. Flow is defined in terms of calling the base functions being exposed by the Reusable library components. The manner in which the end user will access the application defines the sequence in which base functions should be listed out.
Generally one or more test scripts are combined to make the test scenarios in order to test the particular feature. Example: one scenario can be – Open Application User Login Check/Change Account settings Close Application.
4. Test Reports
The result of running the tests should be well presented to concerned stakeholders for decision making. So the reports generated after execution of test steps should be stored in Test Reports folder separately from business logic and verification logic.
They can be stored in HTML or other formats as defined as per business needs.
5. Test Data
The set of test data is always required to check the adequacy of the AUT. This section holds the entire test data (like input parameters and expected results) needed in AUT. Test data can be generated as per the demand or it can be real test data used in the AUT.
Example: It can hold application details like application server address, port number; User login credentials; supported browsers; expected outcomes, etc.
6. Test Configuration
Predefined configuration settings needed in AUT are stored in .config file. It’s a XML schema file used to store the data that is needed at AUT runtime. Web applications typically have a web.config, while Windows GUI/service applications have an app.config file.
Conclusion:
Properly defined and well organized Automation framework plays a vital role in software testing industry. The above guidance on components is required for any efficient framework but this is not limited to only these components. This approach can help the teams to design and build the right automation frameworks. Well, there will always remain a scope for improvements and suggestions.
Image Courtesy: http://goo.gl/hxzPt5
To design an effective automation framework which helps reduce the release cycle and accelerate market release, application-independent test automation frameworks become a necessity. Components such as function libraries, test data sources object details and various other reusable modules act as building blocks. These blocks are assembled to create a business process framework and provides basis for test automation and also simplifies the automation efforts.
The illustration below explains the situation where Page Object Model acts as a backbone.
The following components are included in Application under Test (AUT):
1. Reusable Library
Reusable library consist of common functions that can be reused application wide. It also acts as a repository for the all the objects and elements of AUT.
Example: Login page is a class file that contains base functions and their objects. As you can see Page elements and associated functions are defined in one single class. These functions will be exposed to the verification layer of the AUT where the tests use them.
2. Shared Resources
It contains the collection of utilities and resources that are shared in the entire application. It may be like handling different types of browsers, managing different parser utilities which in turn can be used to fetch data from different file formats and make them consistent for use in AUT, or defining preconditions that should be called before test verification begins.
3. Test Scripts
This section is the Verification layer of AUT. It contains Test scripts which performs the task for carrying out the verification of AUT. They define the entire flow for verifying the specific feature of AUT. Flow is defined in terms of calling the base functions being exposed by the Reusable library components. The manner in which the end user will access the application defines the sequence in which base functions should be listed out.
Generally one or more test scripts are combined to make the test scenarios in order to test the particular feature. Example: one scenario can be – Open Application User Login Check/Change Account settings Close Application.
4. Test Reports
The result of running the tests should be well presented to concerned stakeholders for decision making. So the reports generated after execution of test steps should be stored in Test Reports folder separately from business logic and verification logic.
They can be stored in HTML or other formats as defined as per business needs.
5. Test Data
The set of test data is always required to check the adequacy of the AUT. This section holds the entire test data (like input parameters and expected results) needed in AUT. Test data can be generated as per the demand or it can be real test data used in the AUT.
Example: It can hold application details like application server address, port number; User login credentials; supported browsers; expected outcomes, etc.
6. Test Configuration
Predefined configuration settings needed in AUT are stored in .config file. It’s a XML schema file used to store the data that is needed at AUT runtime. Web applications typically have a web.config, while Windows GUI/service applications have an app.config file.
Conclusion:
Properly defined and well organized Automation framework plays a vital role in software testing industry. The above guidance on components is required for any efficient framework but this is not limited to only these components. This approach can help the teams to design and build the right automation frameworks. Well, there will always remain a scope for improvements and suggestions.
Image Courtesy: http://goo.gl/hxzPt5[:]
