These are the most frequently asked data-driven testing questions across Infosys, TCS, Wipro, Cognizant, Accenture, and product companies. Many of these were already covered in earlier lessons, but here they are collected for quick revision.
Q: How do you implement data-driven testing in your framework?
A: We use TestNG @DataProvider to inject test data into test methods. For small data sets, we define data inline. For larger sets, we read from external files — CSV for simple tabular data, Excel for data managed by the business team, and JSON for complex nested structures. We have a centralized DataProviders class that all test classes reference using dataProviderClass. Utility classes like ExcelUtils and CsvUtils handle file reading.
Q: What is the difference between @DataProvider and @Parameters?
A: @DataProvider returns Object[][] and runs the test once per row — ideal for testing one feature with many input combinations. @Parameters reads single values from testng.xml — ideal for environment-level config like browser type or base URL. We use @DataProvider for test data and @Parameters for cross-browser setup.
Q: How do you handle different cell types when reading Excel with Apache POI?
A: We have a getCellValue() utility method that checks cell.getCellType() and handles each type: STRING returns the string value, NUMERIC checks if it is date-formatted (using DateUtil.isCellDateFormatted) and returns the date, otherwise converts to string while avoiding the ".0" suffix for whole numbers. BOOLEAN converts to string. FORMULA tries getStringCellValue first, falls back to getNumericCellValue. NULL and BLANK return empty string.
Q: How do you manage test data across different environments?
A: Configuration goes in config.properties with a ConfigReader singleton that checks System.getProperty() first. In CI/CD, we pass -Dbase.url=... -Dbrowser=... via Maven command line to override file defaults. For test data that varies by environment, we use separate sheets in Excel or separate CSV files per environment.
Q: Can you share a DataProvider across multiple test classes?
A: Yes. I create a centralized DataProviders class with all @DataProvider methods. Test classes reference it using dataProviderClass: @Test(dataProvider = "loginData", dataProviderClass = DataProviders.class). This eliminates duplicate DataProvider code and centralizes data management.
Q: What type of framework do you use? Explain your framework architecture.
A: We use a hybrid framework built on POM with data-driven testing. The architecture has these layers: config.properties for configuration, ConfigReader singleton for reading config with CI/CD override support, BaseTest for browser setup and teardown, Page Object classes for each page, centralized DataProviders class with ExcelUtils/CsvUtils for external data, TestNG for execution, Maven for build management, and Allure for reporting. Test data comes from Excel and CSV files stored in src/test/resources/test-data/.
Q: When would you use CSV vs Excel vs JSON for test data?
A: CSV for simple tabular data — easy to edit, version-control friendly, no dependencies. Excel when the business team manages data and needs formatting, colors, or multiple sheets — requires Apache POI. JSON when data has nested or hierarchical structure — like API payloads or transfer scenarios with nested account objects. In our framework, we use all three based on the use case.
Q: What happens if your DataProvider throws an exception?
A: If the DataProvider throws an exception (like FileNotFoundException or IOException), TestNG marks ALL tests that depend on that DataProvider as SKIPPED, not FAILED. The exception details appear in the test report. This is why we always validate file existence and handle exceptions properly in DataProvider methods.
Q: How do you handle sensitive test data like passwords?
A: Sensitive data like passwords and API keys are never committed to version control. We use environment variables (System.getenv()) for secrets. The CI/CD pipeline injects them at runtime. For local development, we use a .env file that is in .gitignore. The ConfigReader checks System.getenv() for secrets and falls back to environment-specific config files for non-sensitive data.
Q: What is the advantage of using the POJO approach with Jackson for JSON test data?
A: The POJO approach gives compile-time type safety. If a field name changes in the JSON, the compiler catches it. IDE auto-complete works on field names. You get clean getter/setter access instead of navigating JsonNode with string keys. It is the recommended approach for production frameworks with complex JSON structures. The trade-off is that you need to create and maintain Java classes matching the JSON structure.