Sorry, you need to enable JavaScript to visit this website.

Modern Automation for Legacy Product

Modern Automation for Legacy Product
December 20, 2018

In the modern age of product development, most of the software/hardware modules are readily available. So, the developer can spend most of the time in the design and module interface. And next is the testing stage where this can be done in two ways - manual testing and automation testing.

Legacy products are currently running their automation testing through the eDAT automation tool.

Depending on the test report and the customer feedback, feature addition and bug fixing can happen in the software. So, different versions of software releases will be there. Each version of the software must test using the same test cases again and again if it is a manual testing.

Manual testing is the traditional way of testing and it’s having a lot of disadvantages compared to automation testing tools. So, most of the product developers have started using automation testing at some levelbecause 100% of automation cannot possible, so the remaining test cases can be done by manual testing.

There are some open source and paid tools available for automation testing depending upon the product, like web application and PC application. This can be done by using test automation tools like Selenium, QTP etc. And for Embedded products, we can use RTRT for unit testing, CANoe for communication interface testing, and eDAT for embedded system testing etc.

Script is the front end for the automation testing tools where the users can interact and develop their own scripting flow with respect to the test cases. And most of the time, the scripting activity will be a one-time activity during the test phase or it may require some fine-tuning depending on the past testing results or any requirement changes. Lastly, scripts can execute through the automation tool to run the test automation.

Some of the scripting languages include Python, PowerShell, Jscript, C scripting, Perl, Julia, Ruby, VBscript etc.

Problems in using test automation tool scripting:

Automation testing tools have a limitation to support all the above scripting languages. Each automation tool can support most of the scripting languages but not all.

New scripting language or New Automation tool migration:

Most of the legacy product test scripts are developed using traditional scripting languages like “C” script and VB scripting. And the new automation tools may not have a support for some of the above traditional scripts. So, the testers need to rewrite the test cases scripts with respect to the new automation tool supporting script language. This going to happen in future too, because the technology migration will be always there. So, the testers need to rewrite the script for their legacy product or legacy product upgrade. Along with this, most of the new or upgraded product features will be leveraged from the legacy product, so the 50% or 60% of the new product test case will be similar to the legacy product. Finally, to automate the testing of legacy product, an updated legacy product or the new product which is having similar features, need rewriting of script because of technology migration.


The above problem can be overcome by using the server client approach between the test automation tool and the script engine. The test automation tool should act as a server and the script engine should act as a client, and the server should perform the automation feature on the demand of main script client request. Figure 1 defines the automation setup and here, both automation tool and main script run in the same PC, So both, the server and client connect like local host TCP/IP.


All automation tool features can be enabled and disabled through the TCP/IP messages. The automation tool vendor should define the messages protocol and its format with respect to the features along with the required parameters. TCP/IP Client should have an abstraction layer (refer Fig 2) which can be replaceable to adopt the different automation tool protocols (server).


The testers or developers should develop the TCP/IP client protocol by using their own scripting language. The test script should contain the connection establishment with the server (Automation tool) during the initialization stage of the test script and later, all the test steps should be there, and at the end, the script should properly disconnect the client from the server (Refer Fig 3).

With respect to the test step, the Test Script should send the feature-enabled messages along with the required parameters to the Automation tool (server). For example, to compare the DUT display image with the reference image, it requires parameters like, both the image location in the PC storage or cloud storage. Now, the automation tool server receives the message and performs the image compare computation by taking the images from the locations which are sent by the client as a parameter. This can be done similarly for the other features.

Currently, most of the automation tools don’t have a server enablement feature. So, the script developers can develop their own defined protocol server using the script language which is supported by the automation tool or user can develop it by using any programming language like C, C++, C# etc which can be referred directly in scripting supported by automation tool. And all these are a one-time activity during the test automation setup.

An automation tool vendor need not support all the scripting languages. Instead, the vendor can provide only the client abstraction layer for different scripting languages which can be directly used in the main Test script development (Ref the Fig 2 green block).

The eDAT automation tool overcomes the above issue by providing the server enablement script and client abstraction layer for the legacy scripting languages (example C scripting). Using the same, some of the Legacy products are currently running their automation testing through the eDAT automation tool.


One of the main disadvantages in this idea is, Message transition delay gets added in the test sequence, because each and every feature of the automation tool can be triggered through TCP/IP messaging. And this may affect places where time-critical test sequence is required. But in most of the products, 10 to 20% of the test cases require time-critical sequence and the remaining 80% of the test cases can be automated by using the above idea.