Framework questions are the most important part of any automation interview. Companies want to know that you can architect, build, and maintain a test framework — not just write individual test scripts. Here are the questions that come up in almost every interview, from TCS to Google.
Q: Describe your automation framework. What is the architecture?
A: We use a hybrid automation framework built on the Page Object Model pattern with TestNG and Maven. The architecture has five layers. First, the Base layer — BaseTest handles WebDriver lifecycle with ThreadLocal for parallel execution, and BasePage provides common page actions (click, type, waitForVisible, scrollTo). Second, the Page Object layer — page classes organized by module (banking, shopping) with private locators and public action methods. Third, the Test layer — test classes extending BaseTest, organized by module, using groups (smoke, regression) and DataProviders for data-driven testing. Fourth, the Utility layer — ConfigReader for environment management, ExcelUtils and CsvUtils for test data, ScreenshotUtils for failure evidence. Fifth, the Listener layer — ITestListener for automatic screenshots on failure and IRetryAnalyzer for handling flaky tests. Configuration is externalized in config.properties with system property overrides for CI/CD.
Q: How many tests do you have? How long does a full regression run take?
A: We have around 150 automated tests across three portals. We organize them into three suites: Smoke (15 tests, 3-4 minutes) runs on every deployment, Sanity (40 tests, 10 minutes) runs after every build, and full Regression (150 tests, 40-45 minutes) runs nightly. We use parallel execution with thread-count=3 at the class level, which cuts regression time from 2 hours to 45 minutes. In CI, tests run in headless Chrome inside Docker containers.
Q: What design patterns do you use in your framework?
A: We use four design patterns. Page Object Model — separates page interactions from test logic, each page has private locators and public methods. Factory Pattern — DriverFactory creates the appropriate WebDriver based on browser parameter. Singleton Pattern — ConfigReader loads configuration once and provides global access. Composition — shared components like HeaderComponent are composed into page objects rather than inherited. We also follow the principle of Separation of Concerns — tests, pages, utilities, configuration, and data each live in their own package.
Q: What happens when a test fails? Walk me through the failure handling.
A: When a test fails, four things happen automatically. First, TestNG calls our TestListener.onTestFailure() which captures a screenshot with a timestamped filename. Second, the stack trace and error message are logged via Log4j2 to both console and the log file. Third, if RetryAnalyzer is configured, the test is retried up to the configured limit (usually 1). Fourth, in the BaseTest @AfterMethod, the browser is always closed regardless of test result to prevent resource leaks. After execution, we have: the TestNG HTML report with pass/fail status, timestamped screenshots in the screenshots/ folder, and detailed logs in logs/test-execution.log.
Q: How do you handle test data? Where is it stored?
A: Test data is stored externally in src/test/resources/test-data/ folder, completely separated from test logic. We use three formats: CSV for simple tabular data like login credentials, Excel for complex multi-column data like fund transfer scenarios, and JSON for nested structures. A centralized DataProviders class has static @DataProvider methods that read from these files using our CsvUtils, ExcelUtils, and JsonUtils utilities. Tests reference them with dataProvider="loginData" and dataProviderClass=DataProviders.class. This way, the business team can add new test scenarios by editing data files without touching Java code.
Q: How do you decide what to automate and what to keep manual?
A: I follow the automation pyramid. Automate first: repetitive regression tests that run frequently, data-driven scenarios with many input combinations, smoke tests that verify critical paths, and cross-browser compatibility checks. Keep manual: exploratory testing, usability testing, visual testing (unless using tools like Percy), tests that run once or twice, and scenarios that require human judgment like "does this look right?" The rule of thumb is: if a test will run more than 5 times and can be reliably automated, automate it. If it needs human intuition or runs rarely, keep it manual.
Q: How do you maintain your test suite as the application changes?
A: Maintenance is built into the framework design. With POM, if a page UI changes, I update one page object file — all tests using that page get the fix automatically. ConfigReader handles environment changes without code modifications. DataProviders let me update test data without touching test methods. We run the full regression suite nightly — any broken test is flagged immediately. We also do quarterly test reviews to remove obsolete tests, update flaky ones, and add coverage for new features. The key is that page objects absorb UI changes, and tests only describe business logic.
Q: What is the difference between smoke, sanity, and regression testing?
A: Smoke testing verifies that the basic functionality works after a new build — like checking if the building has electricity after construction (10-15 tests, 3 minutes). Sanity testing checks that specific bug fixes or features work correctly — targeted and narrow (30-40 tests, 10 minutes). Regression testing verifies that existing functionality still works after code changes — the full suite covering every feature (150+ tests, 45 minutes). In our CI/CD pipeline: smoke runs on every commit, sanity runs on every merge to develop, regression runs nightly.
Q: How do you handle dynamic elements or elements that load asynchronously?
A: Explicit waits with ExpectedConditions. I use WebDriverWait with conditions like visibilityOfElementLocated, elementToBeClickable, and textToBePresentInElement. For elements that appear after AJAX calls, I wait for either the element to appear or a loading spinner to disappear. I never use Thread.sleep because it is a fixed delay that does not adapt to actual load times. In BasePage, all interaction methods (click, type, getText) internally use waits, so tests never interact with elements that have not loaded.
Q: What is the Page Object Model? Why do you use it?
A: POM is a design pattern where each web page is represented by a Java class. The class has private locators (By objects) and public methods that represent user actions. Tests interact with page objects, not directly with Selenium. Benefits: if the login button ID changes from "login-btn" to "signin-btn", I update one line in LoginPage.java — not 50 test files. POM provides code reusability, maintainability, and readability. Tests read like user stories: loginPage.loginAs(user, pass) instead of driver.findElement(By.id("username")).sendKeys(user).
Practice the "Describe your framework" answer until you can deliver it in 2 minutes flat without hesitation. This is the single most common interview question for automation engineers. Use the five-layer structure: Base, Pages, Tests, Utils, Listeners. Draw it on a whiteboard if asked.
Answer all 5 questions, then submit to see your score.
1. What is the main purpose of the BaseTest class in an automation framework?
2. Why is ThreadLocal used for WebDriver in the BaseTest class?
3. In a professional framework, where should test data files (CSV, Excel, JSON) be stored?
4. What does the ConfigReader check FIRST when looking for a configuration value?
5. Which parallel setting in testng.xml runs each test class in its own thread while keeping methods within a class sequential?