I’ve finally finished my test case for creating a new bank account, and it works great! But now my boss wants me to test it across 50 different account types (Savings, Checking, Business, Student, etc.) and different currencies.
Right now, the only way I know how to do this is to right-click my test case and “Duplicate” it 50 times, then manually go into each one and change the text in the setText fields. This is taking forever, and I’m already getting confused about which one I’ve updated. Plus, if the developers change the “Submit” button ID tomorrow, I’m going to have to fix it in 50 different places!
use data-driven testing instead of duplicating test cases. define variables in your test case (e.g., accountType, currency) and replace the hardcoded strings with them.
create a data file with columns matching those variables and your 50 rows of combinations. In your test suite, add the test case, click “Show Data Binding”, and map the data file columns to the variables. Katalon will loop the test case once per row automatically.
Duplicating a test case 50 times is a common mistake and should be avoided. While it may work initially, it quickly becomes difficult to maintain, error‑prone, and time‑consuming—especially when UI changes occur, such as an updated Submit button locator. Instead of creating 50–60 separate tests, the recommended approach is to build one reusable test case driven by input data. Using Data‑Driven Testing (DDT) with Data Binding, you can parameterize variables like account type and currency, store them in an Excel or CSV file, and execute the same test automatically for multiple combinations. This eliminates duplication and makes future updates seamless. Additionally, all UI elements should be centralized in the Object Repository rather than hard‑coded in scripts. This ensures that any locator changes need to be fixed only once, providing a major improvement in test maintenance and scalability.
What you are looking for is Data-Driven Testing (DDT). In professional automation, we separate the Logic (the test steps) from the Data (the account types).
Duplicating test cases is a maintenance nightmare. Instead, we use Variables in the Test Case and bind them to a Data File within a Test Suite. This way, you maintain one single script, and if you need to add a 51st account type, you simply add a row to your Excel sheet—no coding required.
The Solution: Data Binding via Test Suites
Create Variables: Open your Test Case, go to the Variable tab, and add variables (e.g., accountType, currency). Replace your hardcoded text in the “Manual” or “Script” view with these variables.
Setup Data File: Right-click Data Files > New > Test Data. Link your Excel or CSV file.
Bind in Test Suite: Create a Test Suite, add your Test Case, and click Variable Binding. Map your Excel columns to your Test Case variables.
Custom Keyword Helper: Data-Driven Navigation
Sometimes you need to select a value from a dropdown based on your data file. Here is a robust keyword to handle dynamic selection from a list based on your Excel data:
import com.kms.katalon.core.annotation.Keyword
import com.kms.katalon.core.testobject.TestObject
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
import com.kms.katalon.core.model.FailureHandling
class DataHelper {
/**
* Selects an option from a dropdown by matching the text from your Data File
* @param to The Test Object for the dropdown
* @param value The value from your Excel/CSV row
*/
@Keyword
def selectOptionFromData(TestObject to, String value) {
if (value == null || value.isEmpty()) {
println "Data value is empty, skipping selection."
return
}
WebUI.waitForElementVisible(to, 5)
// Selects the option that matches the text in your spreadsheet
WebUI.selectOptionByLabel(to, value, false)
println "Successfully selected: " + value
}
}
Architecture Workflow:
Excel: Row 1: “Savings”, Row 2: “Checking”…
Test Case:WebUI.setText(findTestObject('input_Type'), accountType)
Test Suite: Iterates through every row in the Excel file automatically.
Architect’s Tip: When running 50+ iterations, make sure to use FailureHandling.CONTINUE_ON_FAILURE in your Test Suite settings. This ensures that if the 5th account type fails, Katalon doesn’t stop—it logs the error and moves on to the 6th row.
Thanks for the explanation. This actually helped me understand how to avoid duplicating test cases. I haven’t used Data-Driven Testing before, but using variables + Excel file sounds much cleaner than creating many similar tests.