Data-Driven Automation Testing

Data-driven testing is a powerful technique in test automation that enables testers to create data-driven tests that can execute multiple times with different sets of test data.

Automation testing for any website or product is critical in terms of time taken, quality, and cost of the project delivery. Though there are many ways to perform automation testing – Unit, Regression, Smoke, and others – the Data-driven method is repeatedly proven to be the simplest-yet-flexible way since it bridges the gap between the traditional recordable automated tests and the new-age ones. 

The only problem quoted against the former method was its inflexible and non-extendable nature; however, data-driven testing has overcome those complaints and proved to be highly flexible and extendable.

What is Data-Driven Testing? 

Consider a situation where you must automate a test for an application with numerous input fields. In rare cases, you would hardcode those inputs before running the test. But at scale, hard coding will fall short. When you go through numerous combinations of acceptable input values for best-case, worst-case, positive, and negative test scenarios, hardcoding inputs will quickly become complicated, confusing, and impossible to manage.

You could program the test to “read” the input values from a single spreadsheet if all test input data could be recorded or stored there. That is what data-driven testing specifically aims to accomplish.

By separating test data (input values) and test logic (script), DDT makes it simpler to create, edit, use, and scale both. To compare actual and anticipated results for validations, a series of test steps (structured in test scripts as reusable test logic) are automated and run simultaneously for various permutations of data (obtained from data sources).

The four steps of parametrized testing are as follows:

  • Getting input data out of databases or data sources like .xls, .csv, or .xml files.
  • Utilizing automated test scripts and variables to enter input data into the AUT (application under test).
  • Comparing the final results with what was expected.
  • Running the test again with the following row of data (from the same source).

How Data-Driven Automation Testing Works?

The need for automation arises when testers are persuaded to repeat the same task continuously. Such redundant activities create boredom among the testers and thereby will impact productivity. On the other hand, automation testing has one big con – the compulsion to maintain a ton of test data. 

Hard-coding every data in the scripts is proven cumbersome and maintaining the hard-coded script becomes tedious when switching over from one test environment to another.

To avoid such situations, it is convenient, to keep data for automation tests in a separate class file or external file formats like Excel, Word, text file, or even from the database tables. These data are then fed to the automation scripts as parameters at the time of execution.

What is the Data-Driven Testing Framework?

DDT framework allows us to quickly retrieve previously existing code rather than creating it from scratch. Whether retrieving a script from a framework or quickly identifying and fixing script errors, using the software doesn’t require you to be an expert programmer.

The DDT framework is a platform for automation testing that allows you to validate a test case against multiple types of test data with a single test script. All of these values are inputs by the test script, and the test data for both positive and negative testing is saved in a file. As a result, the framework provides reusable logic, which increases test coverage.

We should focus on how to input data and what to expect as output data from the described automated framework. Most importantly, how will we structure this data? This is because the agenda depends on test data in an automated framework.

Data-Driven Testing Framework

Data File: A Data File is the first point of entry for any DDT framework. A typical data file contains test data such as positive and negative test cases, exception throwing and handling test cases, min-max limit cases, and data permutations to ensure adequate data coverage.

Depending on the testing requirements of the application, it can only be deemed “ready” if this data can be parsed using the Driver Script. These data sets can be stored in HDP databases or data storage files such as Excel, XML, JSON, or YML.

Driver Script: As the name implies, Driver Script is code that mimics an application’s test case. It reads information from data files so that test scripts can run the necessary tests on the application.

The structure contains placeholders for variables (test data) taken from the Test File. The output of the script is compared to the “expected results.”

A driver script is typically a short piece of well-written code. The application and implementation codes in a DDT are typically combined in a driver script.

The primary focus of DDT is on how well an application can be evaluated. The problem is how the test data and test script interact to produce the expected results.

Test scripts are frequently hard coded and are typically written to only run “once” for a specific data set. In DDT, everything is dynamically tested with a variety of data sets and factors. We must modify scripts that are not hardcoded (with static data) to handle dynamic data and its behavior while the program is running.

It is the automation tester’s responsibility to write scripts that strike the proper balance between the two.

Actual and Expected Results: This validation is carried out by comparing the actual and expected results. If there are any discrepancies, the underlying cause is identified and evaluated so that it can be corrected. Furthermore, these changes should not affect the expected product workflow. This is achieved by incorporating a dependable feedback loop into the organizational process, which routes these corrections to the appropriate development teams.

Please keep in mind that more test cases may be required during this whole phase to fully validate an instance. In these cases, the Data File and the Driver Script are modified to meet the specifications.

Implementation Of Data-Driven Automation

To implement data-driven testing, testers can use tables that contain related data and actions to execute on the test environment. The reusable test logic is used to create test scripts that can be executed multiple times, which helps in reducing the time and effort required for testing. 

Additionally, testers should ensure that they have configured the test environment settings correctly to avoid any issues during the execution of data-driven tests. 

By implementing data-driven testing, testers can create effective and efficient test scripts that save time and resources while increasing test coverage.

Data-driven automation can be implemented using selenium webdriver and TestNG because it’s an open-source framework and Java supports the external-file libraries and inbuilt functions for implementation.

The following libraries in Java are used to read data from external files:

  • JExcel
  • Apache POI
  • Aspose.cells

Apache POI is the most common library used for reading the values from the various formats of external files such as .xls, .xlsx, .ppt, .doc, .txt, and so on. On the other hand, JExcel can only read from .xl

Though there are loads of file formats, testers prefer to use Excel because it’s easy to add extensive data, extract cell-wise or row-wise data, and columnize based on categories. We have two formats to read the values from the excel files:

  • HSSF(Horrible Spreadsheet Format) – Reads and Writes (.xls) files.
  • XSSF(XML Spreadsheet Format) – Reads and writes (.xlsx) files.

Some other formats will help read and write the values from other Microsoft Office formats.

Before starting the execution, it’s important to add the POI Jar files. Follow the steps below to add Jar files:

  1. Go to build path and select Configure build path.
  2. Click on Add external JAR files.
  3. Search for the POI jar file from the system and add it.

Note: You can download the Apache JAR files here.

There’s a prerequisite to know the following parameters as well:

  • Excel Filename.
  • Filepath.
  • Sheetname.
  • Permission.
  • Structure of the Excel sheet.

Data in Excel

Data in Excel

Steps to Read the data from Excel Sheet

  • Open the Excel sheet using XSSF or HSSF.
  • Go to the specific sheet using XSSFSheet or HSSFSheet→getSheet.
  • Go to the specific row using XSSFRow or HSSFRow→getRow.
  • Go to the specific cell using XSSFCell or HSSFCell→getCell.
  • Read the data from a particular cell by using getStringCellValue().


File src = new File(“path to the excel file”);
XSSFWorkbook wb = new XSSFWorkbook(src);
XSSFSheet sheet = wb.getSheet(“Sheetname”);
XSSFRow row = sheet.getRow(“Rowcount”);
XSSFCell cell= row.getCell();

In the case of a cell containing numerical values, it’s mandatory to add a string “`” as a prefix.

Sample Code

package passdatasfromexcel;
import org.apache.poi.openxml4j.exceptions.InvalidFormatException;
import org.apache.poi.xssf.usermodel.XSSFCell;
import org.apache.poi.xssf.usermodel.XSSFRow;
import org.apache.poi.xssf.usermodel.XSSFSheet;
import org.apache.poi.xssf.usermodel.XSSFWorkbook;
import org.testng.annotations.Test;

public class ReadExcel {

@DataProvider(name = “fetchData”)
public Object[][] readExcel(String sheetName) throws InvalidFormatException, IOException {

//Load the Excel File
File src = new File(“./data/”+sheetName+”.xlsx”);

//Open the Book
XSSFWorkbook wb = new XSSFWorkbook(src);

//Go to Sheet
XSSFSheet sheet = wb.getSheet(“Sheet1”);

//Row Count
int rowCount = sheet.getLastRowNum();

//Column Count
int column = sheet.getRow(0).getLastCellNum();
Object[][] data = new Object[rowCount][column];

// Row – for
for (int i = 1; i <=rowCount; i++) {
XSSFRow row = sheet.getRow(i);

//Column – for
for (int j = 0; j < column; j++) {
XSSFCell cell = row.getCell(j);
data[i-1][j] = cell.getStringCellValue();
return data;

Automation Script

Integrate the Sample code with the automation script

package cclogin;

import org.openqa.selenium.remote.RemoteWebDriver;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;

//importing the Excel code sheet
import utils.Excelutility;

public class CClogin extends Excelutility{
public String testCaseName, testDescription, category, dataSheetName, browserName;

public void setData() {
testCaseName = “CClogin”;
testDescription = “login in account”;
dataSheetName = “blogdatas”; //Excel sheet name
browserName = “Chrome”;

@Test(dataProvider = “fetchData”)

public void loginpage(String url, String uname, String pwd) {
RemoteWebDriver driver;
System.setProperty(“”, “./drivers/chromedriver.exe”);
driver = new ChromeDriver();


In the event of executing the above code, it extends the utils.Excel utility and takes the readExcel method as a reference. Furthermore, with the help of DataProvider it takes the value from the excel and passes through the automation scripts via the parameters declared under the public void class.

Data-Driven Testing Best Practices

Excellent testing practices for data-driven testing are listed below:

  • It is ideal to use accurate data while conducting data-driven testing
  • The test script should contain code for the test flow navigation
  • Drive relevant data into virtual APIs
  • Drive Dynamic Assertions using Data
  • The results of tests can be positive or negative
  • Data-driven functional tests should be modified for security and performance


To create high-quality apps, testing is essential. Data-driven testing has always been the most intriguing because it allows for unlimited creativity and information. Businesses should employ data-driven testing from a next-generation QA and independent software testing services provider to hasten the release of high-quality products and improve user experience.

The most important lesson to take away from the information given above is to learn how to maximize the benefits of data-driven testing and apply it to raise the caliber of the testing process as a whole as well as the final product.


TestNG Data Provider with Excel
Data Driven Framework (Apache POI – Excel)

Hope this turned out to be useful.

Prasanna Venkatesh

Prasanna Venkatesh is a Senior Quality Analyst. He enjoys the experience of successfully delivering Quality Products and Services. He is passionate about everything in QA and takes ownership of every task.


  • Pingback: Peter Hosey
  • Pingback: John wills

Leave a Reply