Guide Test Automation

AlexQin

Identifying Requirements can be Automated

Every tool has its own limitations. A feasibility study needs to be conducted for the requirements against the tools. This study would result in listing requirements that can be automated. Also based on the nature of the requirements, automation feasibility needs to be identified.

AlexQin

Design Test Automation Framework

Generally, testers start creating test scripts based on the scenarios. This includes multiple actions to be performed against each objects. This approach leads to an ad-hoc test script creation and duplicate testing effort, i.e. testers, would create test scripts for a single action in different scenarios.

Our approach takes a different path as explained below. For designing a framework, various elements need to be taken into consideration. Utilities/Components (re-usable) would be designed for the following elements that include (not limited to):

• Actions to be performed - Identification of actions to be automated for each object of the application
• Communicating Systems - Study of different internal systems, third-party systems and their communication methodology
• Business Rules - List of business layers and any specific algorithm has to be studied. A separate function needs to be created for each specific algorithm.
• Database Communication - Database validation and check point validations
• Communication with additional automation tools - In the scenario, where we would require communicating with different automation tool. All the communication requirements needs to be identified and designed
• Data retrieval - Retrieval of data from multiple input data stores
• Schedulers - Functionalities related to invoking of relevant scripts based on scheduler configuration
• Tool Extensibility - Overcoming tool limitations. Components for actions/validations for which the tool does not provide any support
• Device Communication - Device communication and data transfer related actions/validations
• Log - User-defined logs for analysis
• Error Handlers - Error handlers to handle known and unknown errors and log the information
• Custom Messages - Display of relevant defined messages
• Result Presentation - Customized and presentable reports on completion of test execution
  
  

Test automation framework would be designed based on the listed factors, using the following guidelines.

• Application-independent.
• Easy to expand, maintain, and perpetuate.
• Encapsulate the testers from the complexities of the test framework
• Identify and abstract common functions used across multiple test scripts
• Decouple complex business function testing from navigation, limit-testing, and other simple verification and validation activities.
• Decouple test data from the test scripts
• Structure scripts with minimal dependencies - Ensuring scripts executing unattended even on failures
  
  

AlexQin

Design Data Input Store

Types of input data files supported by the tools, needs to be identified. Based on the requirements, input files can be categorized as (not limited to),

• Objects Identifier - Object identification syntax respective to the tool, mapped to the logical object name. For example,"A username textbox in the registration page mapped to logical object name - regUName"
• Scenarios/Workflows/Transactions based input - Complete set of input data for different scenarios/workflows/transaction. Each scenario/workflow/transaction translates to "n" number of test cases. This test case based user input benefits the team during future enhancements, in a way that multiple input data can be added using the Test Case ID. For example, "A complete financial transaction order processing, which invokes web services methods for order processing. In this case, input data is created based on test case id". TestCase (TC) 1 would be entering account details, TC2 Order details etc ...
• Custom Message - This can contain custom messages to be displayed for known and unknown errors.
• Driver - File can contain list of file/transaction/workflow id's to be referred to, for a selected batch execution/group of test case executions
  
  

For all the files types, file format needs to be identified and prototyped based on the input data storage.

AlexQin

Develop framework

Framework development is facilitated using the same set of identified tools. Scripting language supported by the test automation tool is used to create the components. Tool extensibility utility/component can be developed using a different language. Utility functions/components created based on framework design is explained in Step 7.

In addition to the re-usable components driver scripts and worker scripts needs to be created.

• Driver Scripts - Scripts that execute a set of transactions, by invoking relevant re-usable utilities/components for each test case. Driver scripts can be mapped to a group of test cases related to a scenario/transaction/screen/window.
• Worker Scripts - Scripts that execute the driver scripts. Worker scripts are group of driver/individual scripts to execute in a batch mode. Worker scripts produce the final results, for the executed batch.
  
  

Approaches for developing re-usable utilities/components include:

• Record/Replay - Used to identify the object recognition pattern, of the specific tool. Very minimal usage
• Screen/Window/Transaction - Used to identify different scenarios to execute scripts in batches.
• Action/Keyword - Invokes the relevant utility/components to perform actions on specific objects. Driver scripts are created based on this input
• Data Driven - Input to keyword driven approach, where validation needs to be performed using multiple input combinations.
  
  

AlexQin

Populate Input Data Store

Input data store needs to be populated based on the file structure defined in Step 6. Data can be populated either manually or in an automated fashion from different data-sources. Test data would be populated based on parent-child hierarchy. For example,

"A transaction would be a parent hierarchy and Input to the test cases would be the child"

Configure Schedulers

Scheduler requirement needs to be identified. Schedulers can be configured to run a worker script (batch script) on a specific time period. This approach benefits in a way that even a business user can configure the scheduler and make the test execution happen.

AlexQin

Key Benefits of Framework
Standard process in Production

- Test automation processes, a single standard is established across the organization. This helps the organization as they follow the standard processes as compared to pre-empted ad-hoc processes, which yield no results.

Free from dependencies

- Complete coding and component usage standards are defined in production. Organization benefits include:

• Independency from the individual coding standards and the utilities/components created
• Complete documentation helps the organization in inducting the new members with minimal effort
  
  

Complete Coverage

- Requirements are collected from an overall organization's perspective (for eg: Product suite on multiple technologies .net and java etc). Overall coverage of re-usable components which includes (data communications, system communications, schedulers, loggers, reporters etc)

This overall coverage minimizes the testing effort during the later stages of the releases, for the entire product suite across the organization.

Future Enhancements Support

- Organizations need not worry about testing future enhancements. Only the validations related to the enhancements need to be added to the existing base framework, and that too with minimal effort.

Cost Estimation

- At the end of Step 6, the complete cost for the framework development can be estimated. This cost includes,

• Acquisition cost - In the procurement process of the tool, following cost needs to be considered:
  
  • Tool Cost
  • Cost based on number of licenses, based on our requirements
  • Tool Support Cost (On-line, Telephone)
  • Version Upgrade Cost
    
    
• Training - Training cost incurred for training test engineers, business users, developers and creating supportive training documentations must be taken into consideration
• Environment - Cost involved in setting up the system environment (Hardware and Software) must be taken into consideration
• Development - Development cost can be calculated based on the components designed in the framework development - Step 6
• Maintenance - Each tool has its own maintenance requirements. Some tools may demand for part-time, some tools demand for a dedicated resource maintaining the tool. Based on the tool's requirements, this cost needs to be calculated
  
  

AlexQin

Conclusion

Having seen the benefits, the importance of testing and test automation will be increasingly realized across domains and to accelerate the process. "Test Automation Framework" would find greater acceptance and importance in the industry.

AlexQin

Source: https://www.thoughtworks.com/insights/blog/guide-test-automation

AlexQin

good job