Feasibility-Anaysis-in-Test-Automation

Many of us may believe that test automation refers just to the automation of test scenarios and their execution. However, both scripting and execution are essential parts of the automation process life cycle. The following phases make up the entire automation process:

  • Automation feasibility Study
  • Test Strategy
  • Test Environment Setup
  • Test Script designing
  • Test Script Execution
  • Defect Analysis and Fixing

PS: The automation process life cycle may differ from one company to the next.

Automation Feasibility Analysis

In this post, we will focus on the very first step of the automation process, i.e. “Automation Feasibility Study”.

Before we begin automating the manual test cases, we must first determine whether we can proceed with the automated test cases. Let’s look at an example to help you grasp it better:

Without seeing the test cases, an automation team was assigned 500 test cases to automate and a time estimate of 30 days. When they began automating it, they ran into problems with item recognition, functional flow, and a variety of other challenges. As a result, the delivery of the scripts is delayed.

If you don’t want to be in the same tumultuous position, you must have a solid automated procedure in place. The feasibility analysis should be the initial stage in this procedure.

“In automation testing, feasibility analysis refers to a checklist that we use to determine if we should automate the test cases or not.”

This checklist consists of various factors upon which automation can be decided. Some of them are as follows:

Functional Knowledge of Application

It is critical to understand the application’s functional flow before beginning automation testing. The automation team need proper knowledge transfer (KT). Manual testers or developers can provide this knowledge transfer. This will make it easy for automated testers to partition test cases according to functionality and do feasibility studies.

Status of development of the Application

The development of the application should be frozen before the automation of the application begins, or else it will require more effort to adjust the script every time in the same cycle, causing the entire automation life cycle for that release to be delayed. In a nutshell, automation is only applicable to stable applications.

Required Access/Privileges for the application is granted to automation tester or not

Automation tool is able to identify the application in form of objects or not

This is yet another crucial need that must be met before we move on with automation. The program is divided into the number of items for UI automation. Only if the proposed automation tool can detect these things can we proceed with the automation; otherwise, automation with that tool is not possible. The only option left is to use another automation tool to identify the application’s objects.

See also  Keep up your Automation execution with Prompt notification

Percentage of the automation that can be achieved in application

When considering the automation of a certain application, we must first determine the minimal proportion of automation that is permissible. In most organizations, this figure hovers around 70%.

Return on investment(ROI)

During the automation process, we encountered a variety of costs, including tool costs, script creation costs, execution costs, and so on. As a result, it is vital to envisage the profit that automation will bring to a company over a long period of time. Different organizations calculate ROI in different ways. The following is a simple formula for determining ROI:

                          Return                 What you get out      Benefits
ROI         =  —————  =     ——————–  =  ———–
                        Investment          What you put in           Cost
 
Benefits is calculated in the below manner.
 
TS = TM – TA
 
Where,
TS = Time saved due to test automation
TM = Time taken for manual testing
TA = Time taken for automated testing
 
Investment is given by:
CA = CHS + CDM+ CT
 
Where,
CA = Cost of automation
CHS = Cost of hardware and software (this can be apportioned over many testing engagements)
CDM = Cost of developing and maintaining automation script
CT = Cost of training staff on automation tools (this can be apportioned over many testing engagements)
 
 As a function of time, the ROI for automation is sometimes defined as:
 
 
                            Delta (Benefits from automation over manual)
ROI (t) =      ———————————————————–
                            Delta (Cost of automation over manual)
 
 
 
                                    Net Quantifiable Benefit
ROI         =              ——————————–
                                               Net Cost
 
The key parameters that should be considered while initializing the ROI exercise are:
  • Understand the focus of automation with respect to reducing testing cycle time, maximizing test coverage, reaching the market faster, cost benefits, etc.
  • Estimate the regression test repository, with respect to effort and cost
  • Choice of test automation tools
  • Automate the entire regression test suite versus taking incremental automation approach
  • Understand the product life cycle and its technology road map
  • Test Automation Framework design

In the end I would like to say that the points written above are only the subset of the overall automation feasibility checklist. But these must be included in any automation testing checklist. Apart from these points, the checklist may vary according to the organizations.

 
Happy learning!!!!

4 COMMENTS

  1. Hi,
    its a well article on Automation Feasibility Analysis.
    Thank u so much.
    But, i am unable sample checklist. When i click on link, page showing a message as “package is not available”
    Can u please send document to my mail id “gadiparthi122@gmail.com”
    or
    see the to download from the site.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.