Scenario-based questions have no single right answer. The interviewer evaluates your thought process, not a textbook response. Think out loud, consider trade-offs, mention alternatives, and explain your reasoning. The best candidates ask clarifying questions before answering.
Q: How would you automate a login page from scratch?
A: First, I analyze the page: identify all elements (username, password, login button, error message, forgot password link, social login buttons). Then: (1) Create LoginPage POM class with private locators and public methods: enterUsername(), enterPassword(), clickLogin(), getErrorMessage(), login(user, pass). (2) Create LoginTest extending BaseTest with data-driven scenarios: valid login (verify dashboard loads), invalid password (verify error message), empty username (verify validation), empty password (verify validation), locked account after 3 failures. (3) DataProvider with Excel or inline data covering all combinations. (4) Assertions: for success — verify redirect to dashboard URL and welcome message. For failure — verify error message text and that we stay on login page. (5) Additional tests: SQL injection attempt in inputs, XSS in inputs, session persistence after login. I start with the happy path and progressively add edge cases.
Q: How would you automate an e-commerce checkout flow?
A: I break it into page objects: HomePage (search), ProductListPage (filter, select), ProductDetailPage (add to cart), CartPage (verify, update quantity), CheckoutPage (shipping, payment), ConfirmationPage (verify order). Test scenarios: (1) Happy path — search product, add to cart, checkout with valid card, verify order confirmation and order number. (2) Empty cart checkout — verify error. (3) Invalid payment — verify error message and that the order is NOT placed. (4) Discount code — apply valid and invalid codes, verify price recalculation. (5) Multiple items — add 3 items, verify cart total. (6) Quantity change — update quantity in cart, verify total updates. I use Soft Assert on the confirmation page to verify all fields at once: order number, item names, prices, shipping address, payment summary. Test data (product names, card numbers) comes from Excel via DataProvider. I create user accounts via API in @BeforeSuite for speed.
Q: How would you automate a dynamic data table?
A: Dynamic tables have rows that change based on filters, search, or real-time data. My approach: (1) Locate the table: By.cssSelector("table.data-table"). (2) Get all rows: findElements(By.tagName("tr")). (3) Utility method getTableData() that returns List<Map<String, String>> — reads headers from <th> and maps each row. (4) Find a specific row by text: XPath //table//tr[td[text()="John Doe"]]. (5) Click an action button in a row: //table//tr[td[text()="John Doe"]]//button[@class="edit"]. (6) Verify sort — click column header, extract the column values, verify they are sorted. (7) Pagination — click next, collect data, repeat until last page, verify total count. (8) Filtering — select filter, wait for table to reload, verify only matching rows appear. I put all table utilities in the page object so tests read cleanly: tablePage.getRowByName("John").clickEdit().
Q: Your regression suite takes 4 hours. How do you reduce it?
A: Multiple strategies: (1) Parallel execution — configure TestNG parallel="methods" with thread-count=4 using ThreadLocal WebDriver. This alone can cut the time by 60-75%. (2) Remove redundant tests — review the suite for duplicate coverage. If 5 tests all verify the login flow as a precondition, use API login for 4 of them. (3) API-first approach — replace UI data setup with API calls. Creating a user via API takes 200ms vs 30 seconds through UI. (4) Optimize waits — replace any Thread.sleep with explicit waits. A sleep(5000) wastes up to 5 seconds per call. (5) Headless mode — 20-30% faster than headed. (6) Prioritize — run smoke (20 min) on every build, full regression nightly. Not every test needs to run on every commit. (7) Better infrastructure — run on a Grid with multiple nodes or Docker containers. In my project, I reduced 4 hours to 1.5 hours by implementing parallel execution (4 threads) and replacing UI setup with API calls.
Q: How do you decide what to automate vs keep manual?
A: Automate: (1) Repeated tests — regression, smoke, sanity that run every sprint. (2) Data-heavy tests — login with 20 credential sets, form with 50 input combinations. (3) Stable features — core flows that do not change frequently. (4) Cross-browser tests — tedious to repeat manually. (5) API tests — fast and reliable to automate. Keep manual: (1) Exploratory testing — discovering new bugs through ad-hoc exploration. (2) UX/usability — subjective human judgment. (3) One-time tests — migration verification, one-off data validation. (4) Highly volatile features — automate after the UI stabilizes. (5) Visual/aesthetic testing — unless using visual regression tools. My rule: if a test runs more than 3 times and the feature is stable, automate it. I prioritize by business impact: login, core workflows, payment flows get automated first.
Q: A new team member joins. How do you onboard them to your framework?
A: Week 1: (1) Walk through the framework architecture — show the diagram of layers (test, page, utility, config). (2) Show the README with setup instructions — clone, install, configure, run. (3) Run the smoke suite together — explain what happens at each stage. (4) Show a simple test and trace the flow: test method > page object > BasePage > browser. Week 2: (5) Assign them a simple task — write a page object for a new page and one test. (6) Code review their PR thoroughly — check POM structure, naming, wait usage. (7) Show them the CI pipeline and how to read reports. Week 3: (8) Assign a more complex task — data-driven test or a test with multiple page navigations. (9) Pair program on a tricky scenario. Key: a well-structured framework with clear naming and a good README onboards people fast. If it takes more than a day to set up, the framework has a problem.
Q: Tests depend on each other — how do you handle this?
A: The best answer: I eliminate dependencies. Each test should be independent — it creates its own preconditions, runs, and cleans up. If testDashboard needs a logged-in user, the test itself calls the login API (not UI login — that is faster) as part of its setup, not through dependsOnMethods on testLogin. For truly unavoidable dependencies (testing a workflow like create order > pay > track > cancel), I have two options: (1) One long test method with clear sections — this is better because it runs as a single unit and failures are clear. (2) TestNG dependsOnMethods — @Test(dependsOnMethods={"testCreateOrder"}). If createOrder fails, cancelOrder is SKIPPED. I limit chains to 3 tests maximum. Why independence matters: independent tests can run in parallel, can run in any order, can be re-run individually, and are easier to debug.
Key Point: Scenario questions test thinking, not memorization. Always explain your reasoning, mention alternatives you considered, and ask clarifying questions.