Data-driven testing shows you can handle real-world scenarios where the same test runs with dozens of input combinations. Interviewers want to know HOW you read data from Excel/CSV/JSON and plug it into your tests, not just the concept.
Q: What is data-driven testing? Why is it important?
A: Data-driven testing separates test logic from test data. Instead of writing 10 separate test methods for 10 login scenarios (valid, invalid password, empty fields, locked account), I write ONE test method that reads input from an external source — Excel, CSV, or JSON. The test runs once per data row. Why: (1) No code duplication — one test method covers all variations. (2) Easy to add new scenarios — add a row to the spreadsheet, no code change. (3) Non-technical team members can add test data without touching code. (4) Covers edge cases — easy to add boundary values, special characters, long strings. In my framework, I combine TestNG DataProvider with ExcelReader: @Test(dataProvider="loginData") public void testLogin(String user, String pass, String expected) { loginPage.login(user, pass); assertEquals(getResult(), expected); }.
Q: How do you read test data from Excel in your framework?
A: I use Apache POI to read Excel files. My ExcelReader utility class: constructor takes the file path and sheet name. Method getTestData() returns List<Map<String, String>> — each map is one row with column headers as keys. Implementation: open the workbook with XSSFWorkbook, get the sheet, read the header row to get column names, then iterate each data row and create a Map for each. In the DataProvider: @DataProvider public Object[][] loginData() { List<Map<String, String>> data = ExcelReader.getTestData("testdata/login.xlsx", "Sheet1"); return data.stream().map(row -> new Object[]{row}).toArray(Object[][]::new); }. The test method receives Map<String, String>: @Test(dataProvider="loginData") public void testLogin(Map<String, String> data) { loginPage.login(data.get("username"), data.get("password")); }. Accessing by column name (data.get("username")) is more readable than index-based access.
Q: Excel vs CSV vs JSON — which do you use for test data and why?
A: Excel: best for large, structured datasets with multiple columns. Non-technical testers can edit it. I use it for: login credentials, form data, product catalogs. Downside: requires Apache POI dependency, binary format makes Git diffs useless. CSV: lightweight, plain text, Git-friendly. I use it for simple data sets with few columns. Easy to read with BufferedReader — no external library needed. Downside: no data types, no multiple sheets, quoting issues with commas in data. JSON: best for complex, nested data structures — API request bodies, configuration. Easy to parse with Jackson or Gson. Git-friendly. I use it for: API test payloads, complex form data with nested fields. My default: Excel for UI test data (testers are comfortable with spreadsheets), JSON for API test data (matches the request/response format).
Q: What is ConfigReader? How do you implement it?
A: ConfigReader is a Singleton class that loads config.properties once and provides getter methods for the entire framework. Implementation: private constructor loads the properties file. Private static instance variable. Public static getInstance() creates the instance on first call. Getter methods: getProperty(String key), getBrowser(), getBaseUrl(), getTimeout(). The file has: browser=chrome, baseUrl=https://www.testerrank.com, timeout=10, headless=false, environment=qa. ConfigReader checks system properties first (for CI overrides), then falls back to the file: public String getProperty(String key) { String sysProperty = System.getProperty(key); return sysProperty != null ? sysProperty : properties.getProperty(key); }. This lets me override any config from the command line: mvn test -Dbrowser=firefox. Singleton ensures the file is read only once — no repeated I/O.
Q: How do you handle environment-specific test data?
A: I maintain separate data files per environment: testdata-qa.xlsx, testdata-staging.xlsx, testdata-prod.xlsx. The environment is selected through config.properties: environment=qa. My ExcelReader constructs the filename dynamically: String fileName = "testdata-" + ConfigReader.getInstance().getEnvironment() + ".xlsx". This way, switching from QA to staging means changing one config property, not modifying any test code. For URLs and credentials, I use environment-specific config files: config-qa.properties, config-staging.properties. ConfigReader loads the right file based on the environment property. Sensitive data (passwords, API keys) goes in environment variables: System.getenv("DB_PASSWORD"), never in files committed to Git.
Q: How do you handle dynamic or random test data?
A: I use the Java Faker library for generating unique test data at runtime: Faker faker = new Faker(). faker.name().fullName() gives a random name, faker.internet().emailAddress() gives a random email, faker.phoneNumber().cellPhone() gives a random phone number. Why: (1) Parallel execution — two threads creating "John Doe" causes conflicts; random names avoid this. (2) Unique constraints — if the application does not allow duplicate emails, each run needs a fresh one. (3) Realistic data — Faker generates real-looking data, not "test123" or "aaa@bbb.com". I combine static and dynamic data: static data from Excel for expected behavior (valid vs invalid scenarios), dynamic data from Faker for identity fields (name, email, phone). In DataProvider: the Excel row has "RANDOM" as a placeholder, and my reader replaces it with faker-generated data.
Q: What types of data-driven frameworks exist?
A: Three main types: (1) Data-Driven Framework — test data is externalized in Excel/CSV/JSON, test logic is in code. The data source drives the test execution. This is what I use most. (2) Keyword-Driven Framework — actions (open browser, enter text, click button) are stored in a spreadsheet alongside data. An engine reads the keywords and executes the corresponding methods. More flexible but more complex to build. (3) Hybrid Framework — combines data-driven and keyword-driven with Page Object Model. Data comes from Excel, page actions are in POM classes, and the framework supports both coded tests and keyword-based tests. My framework is a hybrid: POM for page interaction, DataProvider for data-driven execution, TestNG for test management, and config.properties for environment configuration.
Q: How do you handle test data cleanup?
A: Every test should clean up after itself. My approach: (1) API cleanup in @AfterMethod — call the DELETE API to remove data created during the test. This is faster than UI cleanup. (2) Database cleanup in @AfterSuite — run SQL scripts to reset the test database to a known state. (3) Unique data per run — using Faker-generated data means leftover data from previous runs does not conflict. (4) Idempotent setup — @BeforeSuite checks if required data exists, creates it if missing, and skips if present. (5) Dedicated test environment — the QA environment database can be wiped and reseeded without affecting anyone. The principle: tests should leave the system in the same state they found it. If a test creates an order, it should cancel/delete that order in teardown.
Key Point: Data-driven testing is about externalizing data from code. Know how to read Excel with Apache POI, use DataProvider, and handle environment-specific data.