A Data-Driven Framework is a Selenium automation framework in which test data is separated from the test script. Instead of writing the same test case multiple times with different input values, a single automation script can read multiple sets of data from external sources such as Excel, CSV, JSON, databases, or TestNG DataProvider and execute the same test logic repeatedly.
The primary purpose of a data-driven framework is to make Selenium automation scripts reusable, maintainable, scalable, and easy to update. When the input data changes, testers can usually update the external data source without modifying the core automation code.
For example, if a login test needs to validate 50 different username and password combinations, a data-driven framework allows the tester to maintain those 50 combinations in a data file and execute the same login test against every data set.
Course Resource: Selenium Training | Register for Course Demo
A Data-Driven Framework is an automation framework design in which test logic and test data are maintained separately. The automation script contains the steps required to perform a test, while the input values required by the test are stored separately.
The same test script can therefore be executed multiple times using different data sets.
Test Script
|
v
Read Test Data
|
v
Execute Same Test Logic
|
+------------------+
| |
v v
Data Set 1 Data Set 2
| |
v v
Execute Test Execute Test
| |
+--------+---------+
|
v
Test Results
Consider a login page that accepts a username and password.
Without a data-driven framework, a tester might write separate test methods for every username and password combination.
loginWithValidUser1();
loginWithValidUser2();
loginWithValidUser3();
loginWithInvalidUser1();
loginWithInvalidUser2();
This approach creates duplicate automation code.
With a data-driven framework, the same test method can be executed using different data.
Username Password
--------------------------------
[email protected] Admin@123
[email protected] User@123
[email protected] Test@123
[email protected] Wrong@123
The automation script remains the same while only the input data changes.
Real-world applications frequently require the same functionality to be tested with many different inputs. A traditional automation script becomes difficult to maintain when every input requires a separate test method.
A data-driven framework solves this problem by separating data from test logic.
| Normal Automation | Data-Driven Automation |
|---|---|
| Data may be hard-coded. | Data is maintained separately. |
| Different data may require different scripts. | One script can handle multiple data sets. |
| More code duplication. | Less code duplication. |
| Maintenance becomes difficult. | Maintenance is easier. |
| Limited scalability. | Better scalability. |
| Test data is closely coupled with test logic. | Test data and test logic are separated. |
The fundamental principle is:
Separate Test Data
+
Separate Test Logic
=
Reusable Automation Test
For example:
Test Logic:
1. Open browser
2. Open application
3. Enter username
4. Enter password
5. Click Login
6. Validate result
Test Data:
Username | Password | Expected Result
The test logic does not need to change for every username and password.
A practical data-driven Selenium framework usually contains several components.
| Component | Purpose |
|---|---|
| Test Scripts | Contains actual test execution logic. |
| Test Data | Contains input values required by tests. |
| Data Provider | Supplies data to test methods. |
| Page Objects | Contains page-specific Selenium actions. |
| Utilities | Provides reusable helper methods. |
| Configuration | Stores browser, URL and environment settings. |
| Assertions | Validates expected and actual results. |
| Reports | Provides execution results. |
| Logging | Records execution information. |
| Build Tool | Maven can manage dependencies and execution. |
| TestNG | Manages test execution and parameterization. |
Test data can be stored in different formats depending on the requirements of the project.
Excel files are commonly used when testers need a structured and human-readable data source.
Username Password ExpectedResult
--------------------------------------------------
[email protected] Admin@123 Success
[email protected] User@123 Success
[email protected] Wrong@123 Failure
CSV files are lightweight and useful for simple tabular test data.
username,password,result
[email protected],Admin@123,Success
[email protected],User@123,Success
[email protected],Wrong@123,Failure
JSON is useful for structured data and is particularly common in modern automation and API testing environments.
{
"username": "[email protected]",
"password": "Admin@123",
"expectedResult": "Success"
}
Test data can also be retrieved directly from a database using JDBC or another database-access mechanism.
TestNG provides a convenient mechanism for passing multiple data sets directly to a test method.
DataProvider is one of the commonly used approaches for implementing data-driven testing with Selenium and TestNG.
It allows a test method to receive multiple sets of input data.
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"[email protected]", "Admin@123"},
{"[email protected]", "User@123"},
{"[email protected]", "Test@123"}
};
}
The test method can consume the data using the dataProvider attribute.
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
System.out.println(username);
System.out.println(password);
}
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest {
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"[email protected]", "Admin@123"},
{"[email protected]", "User@123"},
{"[email protected]", "Test@123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
System.out.println("Username: " + username);
System.out.println("Password: " + password);
// Selenium login steps
}
}
The test method is executed once for every row of data.
@DataProvider
|
v
Returns Multiple Data Sets
|
v
@Test(dataProvider = "loginData")
|
v
Test Method Receives Data
|
v
Execute Selenium Steps
|
v
Validate Result
|
v
Next Data Set
|
v
Repeat Until All Data Is Processed
If a DataProvider contains five rows of data, the associated test method normally executes five times.
Data Set 1 -> Test Execution 1
Data Set 2 -> Test Execution 2
Data Set 3 -> Test Execution 3
Data Set 4 -> Test Execution 4
Data Set 5 -> Test Execution 5
This allows a single test method to cover many input combinations.
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.*;
public class LoginDataDrivenTest {
WebDriver driver;
@BeforeMethod
public void setUp() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get("https://example.com/login");
}
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"[email protected]", "Admin@123"},
{"[email protected]", "User@123"},
{"[email protected]", "Wrong@123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username, String password) {
driver.findElement(By.id("username")).sendKeys(username);
driver.findElement(By.id("password")).sendKeys(password);
driver.findElement(By.id("login")).click();
// Add application-specific validation here
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
For larger projects, hard-coding data inside DataProvider methods is not always convenient. Test data can instead be stored in Excel and read dynamically.
A typical structure may look like this:
TestData.xlsx
|
+-- LoginData
|
+-- Username
+-- Password
+-- ExpectedResult
For Java Selenium projects, libraries such as Apache POI are commonly used to read Excel files.
Apache POI is a Java library commonly used to read and write Microsoft Office document formats, including Excel files.
A simplified Maven dependency can be added to the project as required by the selected Apache POI version.
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>5.4.1</version>
</dependency>
The exact dependency version should be selected according to the project's compatibility and dependency-management requirements.
A reusable Excel utility can read rows and columns from a workbook.
import org.apache.poi.ss.usermodel.*;
import java.io.FileInputStream;
public class ExcelUtils {
public static Object[][] getExcelData(
String filePath,
String sheetName) throws Exception {
FileInputStream file =
new FileInputStream(filePath);
Workbook workbook =
WorkbookFactory.create(file);
Sheet sheet =
workbook.getSheet(sheetName);
int rows =
sheet.getPhysicalNumberOfRows();
int columns =
sheet.getRow(0).getPhysicalNumberOfCells();
Object[][] data =
new Object[rows - 1][columns];
for (int i = 1; i < rows; i++) {
for (int j = 0; j < columns; j++) {
data[i - 1][j] =
sheet.getRow(i).getCell(j).toString();
}
}
workbook.close();
file.close();
return data;
}
}
@DataProvider(name = "excelData")
public Object[][] getData() throws Exception {
return ExcelUtils.getExcelData(
"src/test/resources/TestData.xlsx",
"LoginData"
);
}
@Test(dataProvider = "excelData")
public void loginTest(String username,
String password,
String expectedResult) {
System.out.println(username);
System.out.println(password);
System.out.println(expectedResult);
// Selenium automation steps
}
This approach allows testers to add or modify test data in Excel without changing the test method.
Selenium Test Automation
|
+---------------+---------------+
| |
v v
Test Scripts Test Data
| |
| +-----------+-----------+
| | | |
| Excel CSV JSON
| | | |
+-------------------+-----------+-----------+
|
v
Data Provider
|
v
Page Objects
|
v
Selenium WebDriver
|
v
Application
|
v
Assertions
|
v
Test Reports
The most important characteristic of a data-driven framework is separation.
Test Logic:
Open browser
Open application
Enter username
Enter password
Click login
Validate result
Test Data:
[email protected] | Admin@123 | Success
[email protected] | User@123 | Success
[email protected] | Wrong@123 | Failure
The same logic can process every data row.
A data-driven framework is useful for both positive and negative testing.
| Scenario | Username | Password | Expected Result |
|---|---|---|---|
| Valid Login | [email protected] | Admin@123 | Login successful |
| Invalid Password | [email protected] | Wrong@123 | Error message |
| Invalid Username | [email protected] | Admin@123 | Error message |
| Blank Username | Blank | Admin@123 | Validation message |
| Blank Password | [email protected] | Blank | Validation message |
In real-world projects, Data-Driven Testing is often combined with the Page Object Model (POM).
In this architecture:
Test Data
|
v
DataProvider
|
v
Test Class
|
v
Page Object
|
v
Selenium WebDriver
|
v
Web Application
SeleniumDataDrivenFramework
|
+-- src
| |
| +-- main
| | |
| | +-- java
| | +-- pages
| | | +-- LoginPage.java
| | |
| | +-- utilities
| | +-- ExcelUtils.java
| | +-- ConfigReader.java
| |
| +-- test
| |
| +-- java
| | +-- tests
| | +-- LoginTest.java
| |
| +-- resources
| +-- TestData.xlsx
| +-- config.properties
|
+-- pom.xml
+-- testng.xml
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class LoginPage {
private WebDriver driver;
private By username =
By.id("username");
private By password =
By.id("password");
private By loginButton =
By.id("login");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void enterUsername(String value) {
driver.findElement(username).sendKeys(value);
}
public void enterPassword(String value) {
driver.findElement(password).sendKeys(value);
}
public void clickLogin() {
driver.findElement(loginButton).click();
}
public void login(String username,
String password) {
enterUsername(username);
enterPassword(password);
clickLogin();
}
}
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest {
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"[email protected]", "Admin@123"},
{"[email protected]", "User@123"},
{"[email protected]", "Test@123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(String username,
String password) {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(username, password);
// Assertion
}
}
CSV is useful when the test data is simple and does not require Excel-specific formatting.
username,password,expected
[email protected],Admin@123,Success
[email protected],User@123,Success
[email protected],Wrong@123,Failure
A CSV utility can read each line and convert the values into an Object[][] structure for TestNG.
JSON can be useful when the test data contains nested or structured information.
{
"loginUsers": [
{
"username": "[email protected]",
"password": "Admin@123",
"expected": "Success"
},
{
"username": "[email protected]",
"password": "User@123",
"expected": "Success"
}
]
}
In some enterprise applications, test data may be stored in a database instead of a file.
Database
|
v
JDBC / Database Utility
|
v
DataProvider
|
v
Test Method
|
v
Selenium WebDriver
|
v
Application
This approach can be useful when test data changes frequently or must be retrieved from an existing enterprise data source.
| Data-Driven | Keyword-Driven |
|---|---|
| Focuses on separating test data. | Focuses on separating actions or keywords. |
| Same test logic uses multiple data sets. | Test steps are represented by keywords. |
| TestNG DataProvider is commonly used. | Keyword execution engine is commonly required. |
| Useful for parameterized testing. | Useful for action-oriented test design. |
| Can be combined with POM. | Can also be combined with POM. |
| Linear Framework | Data-Driven Framework |
|---|---|
| Usually contains sequential scripts. | Separates data from test logic. |
| Data may be hard-coded. | Data can be externalized. |
| Limited reusability. | High test-data reusability. |
| Suitable for small scripts. | Suitable for parameterized test scenarios. |
| Maintenance becomes difficult as tests grow. | Better suited to larger data sets. |
TestNG supports parameterization through mechanisms such as @Parameters and @DataProvider. DataProvider is particularly useful when the same test needs multiple data combinations.
@DataProvider(name = "userData")
public Object[][] userData() {
return new Object[][] {
{"John", "[email protected]"},
{"David", "[email protected]"},
{"Alex", "[email protected]"}
};
}
@Test(dataProvider = "userData")
public void createUserTest(String name,
String email) {
System.out.println("Name: " + name);
System.out.println("Email: " + email);
}
A DataProvider can return multiple columns of data.
@DataProvider(name = "productData")
public Object[][] productData() {
return new Object[][] {
{"Laptop", "2", "50000"},
{"Mobile", "3", "30000"},
{"Tablet", "1", "25000"}
};
}
@Test(dataProvider = "productData")
public void productTest(String product,
String quantity,
String price) {
System.out.println(product);
System.out.println(quantity);
System.out.println(price);
}
A practical e-commerce application can use data-driven testing for product searches.
Product Data
|
+-- Laptop
+-- Mobile
+-- Tablet
+-- Headphones
+-- Smart Watch
|
v
Search Test
|
v
Verify Product
|
v
Add to Cart
|
v
Validate Cart
The same automation flow can be executed for every product stored in the data source.
Objective: Automate login functionality using multiple username and password combinations.
| Test Case | Username | Password | Expected Result |
|---|---|---|---|
| TC01 | [email protected] | Admin@123 | Successful Login |
| TC02 | [email protected] | User@123 | Successful Login |
| TC03 | [email protected] | Wrong@123 | Error Message |
| TC04 | [email protected] | Admin@123 | Error Message |
| TC05 | Admin@123 | Validation Message |
Read Test Data
|
v
Launch Browser
|
v
Open Login Page
|
v
Read Username + Password
|
v
Enter Credentials
|
v
Click Login
|
v
Validate Expected Result
|
v
Capture Result
|
v
Execute Next Data Set
Instead of only storing input values, a mature data-driven framework can also store the expected result.
Username | Password | ExpectedResult
-------------------------------------
admin | Admin123 | Dashboard
user | User123 | Dashboard
wrong | Wrong123 | Error Message
The automation script can compare the application's actual result against the expected result.
@Test(dataProvider = "loginData")
public void loginTest(String username,
String password,
String expectedMessage) {
loginPage.login(username, password);
String actualMessage =
loginPage.getMessage();
Assert.assertEquals(
actualMessage,
expectedMessage
);
}
This makes the test completely parameterized because both input and expected output are supplied through the data source.
Data-driven frameworks are especially useful for regression testing because the same test scenarios can be executed repeatedly with multiple data combinations after application changes.
Application Change
|
v
Regression Suite
|
v
DataProvider
|
+---- Data 1
+---- Data 2
+---- Data 3
+---- Data 4
|
v
Execute Tests
|
v
Generate Report
TestNG can support parallel execution depending on how the framework and WebDriver lifecycle are designed.
Parallel execution can reduce overall execution time, but the framework must be designed to prevent shared WebDriver instances and test data from interfering with each other.
Test Data
|
+---- Thread 1 -> Browser 1
|
+---- Thread 2 -> Browser 2
|
+---- Thread 3 -> Browser 3
|
v
Parallel Execution
For parallel execution, thread-safe driver management is important.
When using DataProvider with parallel execution, each test execution should have the correct WebDriver instance.
Data Set 1 -> Driver Instance 1
Data Set 2 -> Driver Instance 2
Data Set 3 -> Driver Instance 3
A poorly designed shared driver can cause data contamination, browser conflicts and unreliable results.
Environment-specific settings should not normally be mixed directly into test data.
A configuration file can contain values such as:
browser=chrome
url=https://example.com
environment=qa
timeout=10
Test data can separately contain:
username,password,expectedResult
[email protected],Admin@123,Success
This keeps configuration, test data and test logic clearly separated.
DataDrivenFramework
|
+-- src/main/java
| |
| +-- pages
| +-- utilities
| +-- factory
| +-- config
|
+-- src/test/java
| |
| +-- tests
| +-- dataproviders
|
+-- src/test/resources
| |
| +-- testdata
| | +-- LoginData.xlsx
| | +-- LoginData.csv
| |
| +-- config.properties
|
+-- testng.xml
+-- pom.xml
Utility classes prevent repeated implementation of common operations.
Typical utilities include:
Test data should be validated before execution.
Examples of validation include:
A robust framework should handle missing or invalid test data gracefully.
if (username == null || username.isEmpty()) {
throw new IllegalArgumentException(
"Username is missing from test data"
);
}
This provides a clear failure reason instead of allowing an unrelated Selenium exception to occur later.
Reports should make it possible to identify which data set passed or failed.
Login Test
|
+-- Data Set 1 -> PASS
+-- Data Set 2 -> PASS
+-- Data Set 3 -> FAIL
+-- Data Set 4 -> PASS
A good report should ideally identify the relevant input values or a safe test-data identifier for the failed execution.
Passwords, API keys, tokens and other sensitive information should not be stored carelessly in source code or publicly accessible Excel files.
For secure automation:
If every data value is hard-coded inside multiple test methods, the framework loses much of the benefit of data-driven testing.
Unstructured spreadsheets with unclear column names can make maintenance difficult.
Input data alone may not be sufficient. Expected outcomes should be defined where appropriate.
Parallel data-driven execution can become unstable when WebDriver instances are shared incorrectly.
Missing or malformed data should be detected before it reaches Selenium actions.
Sensitive information should not be exposed in source code, logs or reports.
START
|
v
Read Configuration
|
v
Load Test Data
|
v
Validate Test Data
|
v
Launch Browser
|
v
Open Application
|
v
Execute Test
|
v
Read Current Row
|
v
Perform Selenium Steps
|
v
Validate Result
|
+-----+-----+
| |
PASS FAIL
| |
v v
Report Screenshot
| |
+-----+-----+
|
v
Read Next Data Row
|
+-----+-----+
| |
Available? No
| |
Yes v
| END
+----->
In real projects, Data-Driven Testing is frequently combined with other framework concepts rather than being used alone.
Hybrid Selenium Framework
|
+-- Page Object Model
|
+-- Data-Driven Testing
|
+-- TestNG
|
+-- Maven
|
+-- Utilities
|
+-- Configuration
|
+-- Reporting
|
+-- Logging
|
+-- CI/CD
|
+-- Selenium Grid
This type of combination allows teams to separate responsibilities and create a scalable automation architecture.
| Technology | Purpose |
|---|---|
| Java | Programming language. |
| Selenium WebDriver | Browser automation. |
| TestNG | Test execution and DataProvider. |
| Maven | Dependency and build management. |
| Apache POI | Excel data handling. |
| CSV utilities | CSV test-data processing. |
| JSON libraries | JSON data processing. |
| Git | Version control. |
| Jenkins | CI/CD execution. |
| ExtentReports/Allure | Test reporting. |
A data-driven Selenium framework can be integrated into a CI/CD pipeline.
Developer Push
|
v
Git
|
v
Jenkins
|
v
Maven Test Execution
|
v
Data-Driven Selenium Tests
|
v
Generate Reports
|
v
Publish Results
This allows automated regression tests to run as part of a software delivery pipeline.
Data-driven testing can also be combined with cross-browser testing.
Test Data
|
+---- Chrome
|
+---- Firefox
|
+---- Edge
|
v
Execute Same Test
|
v
Compare Results
Browser configuration should be managed separately from business test data so that the framework remains organized.
A data-driven framework is useful when:
A pure data-driven approach may not provide much benefit when:
Answer: A Data-Driven Framework is a Selenium automation framework in which test data is separated from test logic. The same automation script can be executed multiple times using different data sets obtained from sources such as Excel, CSV, JSON, databases or TestNG DataProvider.
Answer: TestNG DataProvider is used to pass multiple sets of data to the same test method. It enables parameterized testing and allows one test method to execute repeatedly with different input values.
Answer: Yes. Excel is a common external data source for Selenium automation. In Java projects, Apache POI is commonly used to read and process Excel files.
Answer: Yes. Data-driven testing and Page Object Model solve different problems. Data-driven testing manages test data, while POM manages page-specific Selenium actions. Combining them can improve framework organization and maintainability.
| DataProvider | Parameters |
|---|---|
| Can provide multiple data sets. | Usually provides configured parameter values. |
| Useful for data-driven testing. | Useful for passing configuration or test parameters. |
| Can execute a test repeatedly for multiple rows. | Typically maps parameters from TestNG configuration. |
Answer: Normally, the associated test method will be invoked once for each available data set, resulting in 10 test invocations, assuming all ten rows are returned and no filtering or other execution rules change that behavior.
Answer: In a Java Selenium framework, an Excel utility can use Apache POI to open the workbook, select the required sheet, read rows and cells, convert the values into an appropriate data structure, and provide them to the test through TestNG DataProvider.
| Data Source | Best Use | Advantages |
|---|---|---|
| TestNG DataProvider | Small to medium parameterized tests | Simple and directly integrated with TestNG |
| Excel | Structured business test data | Easy for testers to view and modify |
| CSV | Simple tabular data | Lightweight and portable |
| JSON | Structured/nested data | Flexible data representation |
| Database | Enterprise or dynamic data | Can access centralized data |
Create a Selenium Data-Driven Framework for a login application.
Project: Data-Driven E-Commerce Automation Framework
LoginData.xlsx
|
+-- Login
|
+-- Products
|
+-- Checkout
|
+-- Users
|
+-- ExpectedResults
Use DataProvider to feed the appropriate data into the test methods and POM classes to perform application interactions.
TEST AUTOMATION FRAMEWORK
|
+----------------------+----------------------+
| | |
v v v
Test Scripts Test Data Configuration
| | |
v v v
TestNG Excel/CSV/JSON Properties File
| |
+----------+-----------+
|
v
DataProvider
|
v
Page Objects
|
v
Utility Classes
|
v
Selenium WebDriver
|
v
Web Application
|
v
Assertions
|
+-------+-------+
| |
v v
Reports Screenshots
|
v
Jenkins / CI
| Practice | Recommendation |
|---|---|
| Data separation | Keep input data outside test logic. |
| Reusable code | Use POM and utility classes. |
| Data validation | Validate required fields before execution. |
| Security | Protect passwords and secrets. |
| Reporting | Identify the data set associated with failures. |
| Parallel execution | Use isolated WebDriver instances. |
| Maintainability | Keep files, classes and responsibilities organized. |
| Scalability | Design utilities and data readers for increasing data volume. |
To learn Selenium WebDriver, TestNG, automation frameworks, data-driven testing, Maven, reporting, Git and practical Selenium projects, explore the Selenium training resource below:
For course demo registration and further training information:
A Data-Driven Framework separates test data from test logic so that the same Selenium automation script can execute multiple data sets. Test data can come from TestNG DataProvider, Excel, CSV, JSON or databases.
In a professional Selenium framework, data-driven testing is commonly combined with Page Object Model, TestNG, Maven, reusable utilities, configuration management, reporting, logging, Git, Jenkins and CI/CD. This approach helps create automation suites that are easier to maintain, reuse and scale.
Data-Driven Framework = One reusable Selenium test script + Multiple external data sets + Automated parameterized execution.
