<img height="1" width="1" style="border-style: none;" alt="" src="//googleads.g.doubleclick.net/pagead/viewthroughconversion/1064346053/?value=0&amp;guid=ON&amp;script=0">

Introducing Automation Testing in a Mature Product

image of two people working at computers

This blog discusses the various existing modern-day strategies that can be applied in introducing Automation Testing to a product that primarily relies on manual execution of tests. Generally, product owners seek more clarity on how to automate their test suite given the popularity and positive ROI of the Automation Testing.

Different ways in automating your test suite:

1. To build a business case

A business case must focus on the effort saved as compared to the manual process./ It is therefore essential to identify current areas in the product where automation can have the maximum impact. To derive the data, a common approach is to go by the inputs from the Product Owners, Testers, and Analysts. The existing bug databases and customer feedback are other sources that can provide insights into areas that will benefit most from an automated test suite.

Some common areas to consider for automation:

  • Regression Tests: One of the obvious choices will be the ever-growing regression tests that can be a bottleneck to faster release cycle. For applications that have been in use for a while, regression tests may number in thousands.
  • Test data & Environment setup: Many such applications have requirements around backward compatibility and supporting older operating systems / platforms. Manual setup, periodic testing requires more effort and generally tends to be error prone.

Also, the Developers & Testers can easily highlight the issues they face when they get a newly deployed build or any additional data creation activities that need to be carried out before test execution. These could be other good places to start. Once automated, the data setup part will have a positive impact on the entire regression suite.

2. To begin with Unit tests

Unit tests are meant to test the core of the application code. Starting with the Unit Tests is a great first step as it will immediately start giving an idea of the code coverage. One of the metric that we use to measure the Unit tests is Unit test coverage as shown below:

figure showing unit test coverage

3. Automation & Continuous Integration

Another focus area could be introducing automated deployment processes in the project. The focus is to do ‘continuous testing’ and provide faster feedback which in turn builds confidence in the product. This will lead to a faster release cycles once the entire process of deployment, infrastructure & configuration management is automated.

One of the key metrics will be Minimum Viable Build (MVB). With Automation, churning out builds and the time it takes to complete the cycle of Build > Deploy > Test for its viability should be measured

4. Scalability for the API

The API layer of any project, especially of a project that is in a mature state core of the application. Given that UI changes occur more frequently than middle-tier or API changes in the lifecycle of an application, the service / API layer is an excellent candidate to automate.

Automation of the service layer has advantages such as, it helps to understand the underlying complexity of the application and the execution rate tends to be much better compared to automating the UI.

Additionally, once these API layer tests are automated, the next step is to perform some load testing activity. Tools like JMeter can be easily incorporated in the existing tests which will help to gauge the various performance parameters.

graph showing response time

The above metric shows the response time (in milliseconds) for various endpoints. This is captured based on executing the service layer tests using JMeter.

For a mature product, the stage and the state of the application are additional factors that decide whether the automation is feasible or not.. The analysts, Developers & Testers must be involved to decide on a good set. Eventually, the application is to be evaluated thoroughly for its compatibility with automation. Beginning with a small project (not lasting beyond a couple of months) will give the automation team good time to understand the application and will also be able to show the management a basic automation flow of one of tests. Finally, the discussion can focus on the automation backlog and the QA time will be focused more on exploratory tests.


Related to topics:

Explore other blogs

CMS 21st Century Cures IPA Rule & its Impact on State Health Agencies
CMS 21st Century Cures IPA Rule & its Impact on State Health Agencies
Analytics Opportunities for Payers from CMS Regulations
Analytics Opportunities for Payers from CMS Regulations
Payviders: Enhancing the member experience by creating more personalized digital touchpoints I Part 2 of 2
Payviders: Enhancing the member experience by creating more personalized digital touchpoints I Part 2 of 2


No items currently match your filtering criteria.