Automation Testing Interview Questions

What should I focus on for an automation testing interview?

Can I explain what is worth automating?

Choosing which tests to automate and which to keep manual was the most asked question in these interviews. It appeared in 10 of 109 interviews. Check whether you can explain your choices, not just define automation.

• Which tests would you automate, and which would you keep manual?
• How would you estimate the effort and time needed to automate a set of test scenarios?
• How would you measure success and explain the business value of automation?

Can I walk through a framework from start to finish?

Framework design appeared in 37 of 109 interviews. Questions covered framework structure, reusable code, and patterns such as Page Object Model. Can you explain how you would implement the pattern, rather than just describe it?

Connect the components, rather than just naming them. In 3 of 5 reviewed answers to the maintainable-framework question, candidates did not explain how components work together through setup, test execution, teardown, and reporting.

• Can you follow a test through that full flow?
• Can you explain what each component does along the way?
• Which code would you reuse across tests?

Can I explain tool choices and timing issues?

Questions asked about Playwright's advantages over Selenium, as well as locators, fixtures, browser contexts, and configuration. Can you explain the trade-offs in your Playwright framework structure?

For Selenium, can you name the waits it supports and explain when you would choose explicit waits over implicit waits? For Playwright, can you explain how you would debug a test and handle asynchronous actions?

Can I write the small coding tasks too?

Coding tasks appeared in 8 of 109 interviews. Check whether you can write code for these recorded tasks, not just describe the steps:

• Upload a file with Playwright.
• Read test data from Excel or CSV using Python.
• Make a helper reusable across tests that use different values.
• Use Playwright to click a button.

Can I investigate failures and keep tests reliable?

Can you explain how you would identify, measure, and fix flaky tests while separating them from real defects? Questions also covered unstable selectors, timing issues, and tests that behave differently locally and in CI.

Check the wider workflow too:

• How would you keep test data isolated during parallel runs?
• How would test results control whether a release can proceed?
• What risks arise when AI generates tests, and how would you validate those tests and limit the risks?

Who gets asked Automation Testing

The 20 most asked Automation Testing questions

Counted by interview, not by mention: a question asked twice in one conversation counts once.

1. How do you decide which tests to automate and which to keep manual?

   Asked in 10 of 109 interviews · last asked Oct 18 · Concept · Senior

   Show answer

   I automate tests that run often, cover important risks, and have clear expected results. I compare the time saved and faster feedback with the cost of building and maintaining them. I keep exploratory, usability, and rarely repeated checks manual when automation adds little value. I retire or rework automated tests when their upkeep outweighs their value.

   • Prioritize repeatable regression checks for critical features.
   • Choose tests with reliable setup, controlled data, and clear pass or fail results.
   • Use manual testing where human judgment matters or requirements change often.
   • Review slow, flaky, or duplicate tests; fix useful coverage rather than simply removing it.

   What the interviewer checks: The interviewer wants to see whether you balance risk, repeatability, human judgment, and maintenance cost.

   Other ways it was asked

   • “How do you decide what to automate and what to test manually? What is worth automating?”
   • “How do you decide what to automate, what not to automate, and when to stop automating a test?”
   • “How do you decide what to automate versus what you keep manual?”

2. What is the Page Object Model, and how would you implement it in an automation framework?

   Asked in 9 of 109 interviews · last asked Oct 24 · Concept · Mid-level

   Show answer

   The Page Object Model is a design pattern that separates page interactions from test logic. I create a class for each page, keep its locators there, and expose methods for actions such as login. Tests call these methods and check results. I use it to reduce repeated code and make UI changes easier to handle.

   • Pass the browser driver into page objects so they use the test's browser session.
   • Keep locators, page actions, and waits inside page objects.
   • Keep test assertions in tests; page objects can check that the expected page loaded.
   • Use reusable component objects for shared UI parts, such as navigation menus.

   What the interviewer checks: The interviewer checks whether you can separate UI details from test intent and build maintainable tests.

   Other ways it was asked

   • “What is the Page Object Model, and when would you use it?”
   • “What is the Page Object Model, and how have you used it in test automation?”
   • “What is the Page Object Model, and how do you use it in test automation?”

3. What are the advantages of Playwright over Selenium?

   Asked in 8 of 109 interviews · last asked Oct 22 · Concept · Mid-level

   Show answer

   Playwright offers built-in automatic waits, retrying assertions, network mocking, and detailed test traces. These features reduce setup and help prevent timing-related failures. Its lightweight browser contexts make isolated tests easier and can speed up execution. Selenium supports more languages and browser configurations, so Playwright is not always the better choice.

   • Playwright waits for elements to be ready before actions; Selenium usually needs more explicit wait handling.
   • Browser contexts isolate cookies and storage without starting a new browser for every test.
   • Network mocking and traces help test failures and debug problems without extra tools.
   • Playwright supports Chromium, Firefox, and WebKit; WebKit testing is not the same as testing real Safari.

   What the interviewer checks: The interviewer checks whether you understand Playwright’s practical benefits without claiming it is always faster or better.

   Other ways it was asked

   • “What are the advantages of Playwright compared with Selenium or Cypress?”
   • “Why might Playwright be more convenient and faster than Selenium?”
   • “What is the difference between Selenium and Playwright?”

4. How would you structure a maintainable test automation framework, and what components would you include?

   Asked in 7 of 109 interviews · last asked Oct 8 · Design · Mid-level

   Show answer

   I would separate test cases from page objects or API clients, test data, configuration, and shared helpers. A test runner would manage execution, with fixtures for setup and teardown. Setup creates the required state, tests perform actions and check results, and teardown cleans up even after failures. Reports capture results and failure evidence, and CI runs the suite automatically.

   • Keep test intent and assertions clear; hide UI selectors and request details in reusable components.
   • Keep environment settings separate from test logic, and store secrets securely.
   • Make tests independent, with controlled data and reliable cleanup.
   • Include logs, screenshots where useful, and reports that help explain failures.

   What the interviewer checks: The interviewer checks whether you can design clear components that work together and stay easy to maintain.

   Common mistake (in 3 of 5 reviewed answers): Many answers forget that the components must work together through setup, test execution, teardown, and reporting.

   Other ways it was asked

   • “How would you create a new test automation framework?”
   • “Can you describe the structure and key components of an automation testing framework?”
   • “How is a test automation framework typically structured?”

5. How do you identify, measure, and fix flaky tests while distinguishing them from real defects?

   Asked in 6 of 109 interviews · last asked Oct 18 · Scenario · Senior

   Show answer

   I identify flaky tests by checking results across repeated runs with unchanged code and inputs. I measure inconsistent results over time, not just one successful run. I compare logs, screenshots, timing, and environment details to separate test problems from real product defects. I fix the cause and confirm stability with repeated runs.

   • Track first-run failures and retry passes; retries can hide failures.
   • Check shared data, test order, timing, and environment differences.
   • An intermittent failure can be a real product defect; investigate before blaming the test.
   • Replace fixed sleeps with condition-based waits, isolate test data, and assign owners to temporarily quarantined tests.

   What the interviewer checks: The interviewer checks whether you measure reliability, investigate causes, and fix tests without hiding product defects.

   Other ways it was asked

   • “How do you handle flaky tests?”
   • “How do you identify and handle flaky tests, and what do you do when you find one?”
   • “How would you diagnose and stabilize flaky tests that pass inconsistently?”

6. How would you structure a maintainable Playwright framework, and what trade-offs would you consider?

   Asked in 5 of 109 interviews · last asked Oct 24 · Design · Senior

   Show answer

   I would separate tests, page or component objects, fixtures, and test data, with shared settings in Playwright config. Tests would describe user behavior, while small helpers handle repeated steps. I would keep tests independent and use stable locators, balancing code reuse against extra layers that make failures harder to understand.

   • Use role or test ID locators and auto-retrying assertions; avoid fixed waits.
   • Use fixtures for setup and cleanup; keep each test's data separate.
   • Parallel runs save time, but shared accounts or data can cause conflicts.
   • Collect traces for CI failures, and investigate flaky tests instead of relying on retries.

   What the interviewer checks: The interviewer checks whether you can balance reuse, readability, test isolation, speed, and easy debugging.

   Other ways it was asked

   • “How would you structure a Playwright test automation framework, and what are the trade-offs of that structure?”
   • “What would you improve in an existing Playwright test automation framework if you were rebuilding it from scratch?”
   • “How is your JavaScript Playwright automation framework structured?”

7. What waits does Selenium support, and when would you choose explicit waits over implicit waits?

   Asked in 4 of 109 interviews · last asked Oct 22 · Concept · Mid-level

   Show answer

   Selenium supports implicit and explicit waits. An implicit wait sets how long element searches can retry before failing. An explicit wait waits for a specific condition, such as visibility or clickability. I choose explicit waits for dynamic pages because an element may exist but not yet be ready to use.

   • Implicit waits apply across the session; explicit waits target specific conditions.
   • In Java, FluentWait supports explicit waits with custom polling intervals and ignored exceptions.
   • Avoid mixing implicit and explicit waits; this can cause unexpected delays.
   • Playwright automatically checks action readiness before actions; its web-first assertions also retry.

   What the interviewer checks: The interviewer checks whether you can handle timing issues without fixed sleeps or unreliable element checks.

   Other ways it was asked

   • “Can you explain the difference between explicit wait and implicit wait?”
   • “What types of waits are available in Selenium?”
   • “Which wait is better in Selenium: implicit wait or explicit wait?”

8. What mistakes and risks arise when AI generates automated tests, and how would you limit them?

   Asked in 4 of 109 interviews · last asked Oct 8 · Scenario · Mid-level

   Show answer

   AI can generate tests with wrong assertions, made-up APIs, missed edge cases, or flaky timing. Public AI tools can also expose private code and data. I review tests against requirements, run them, and use only approved tools with safe inputs. I write tests manually when complex rules or high risks make checking AI output harder than writing it.

   • A passing test proves little if its expected result is wrong or it checks the wrong behavior.
   • Check generated APIs, test data, cleanup, and waits to prevent broken or flaky tests.
   • Review coverage against requirements, including failure paths and edge cases.
   • Never send secrets or customer data to public AI; follow company policy for code sharing.

   What the interviewer checks: The interviewer checks whether you can spot unreliable tests, protect company data, and choose when human judgment is needed.

   Other ways it was asked

   • “What challenges have you encountered when integrating AI with Playwright to create tests, how did you address them, and what safeguards do you use to limit errors and hallucinations?”
   • “What are the main risks and limitations of using a public AI in commercial test automation?”
   • “What mistakes does AI commonly make when generating tests, and which are most disruptive to a tester's work?”

9. How would you estimate the effort and time needed to automate a set of test scenarios?

   Asked in 3 of 109 interviews · last asked Oct 8 · Scenario · Senior

   Show answer

   I group scenarios by complexity and estimate the work for each group. I automate a small sample to check those estimates, including test data, setup, coding, debugging, and review. I account for reusable framework features, dependencies, and team availability, then give a time range with clear assumptions and a buffer for unknowns.

   • Check which scenarios are suitable for automation before estimating.
   • Include framework changes, test data, environment setup, and CI integration where needed.
   • Use sample results or past work, not one fixed time per scenario.
   • Separate total work hours from calendar time; waiting and parallel work affect delivery.

   What the interviewer checks: The interviewer checks whether you can build a realistic estimate rather than guess from the scenario count.

   Other ways it was asked

   • “How do you estimate the effort required to automate a user story?”
   • “How do you estimate the effort required to automate a given user story?”
   • “How do you estimate automation effort for a user story in an Agile sprint?”

10. How do you debug Playwright tests and handle asynchronous test execution?

    Asked in 3 of 109 interviews · last asked Jul 22 · Tooling · Mid-level

    Show answer

    I debug Playwright tests with the Inspector, breakpoints, and Trace Viewer to inspect actions, errors, and page state. In JavaScript and TypeScript, I await browser actions and web assertions so steps finish in order. I use Playwright’s automatic waiting instead of fixed delays, and keep parallel tests independent.

    • Run with --debug to open the Inspector; record traces to investigate failures after execution.
    • Await promise-returning calls, including actions and retrying assertions; synchronous code does not need await.
    • Playwright Test runs files in parallel workers by default; tests within each file run sequentially.
    • Use fullyParallel for parallel tests within files; avoid shared accounts or data that tests could change.

    What the interviewer checks: The interviewer checks whether you can investigate failures, handle asynchronous steps correctly, and run tests safely in parallel.

    Other ways it was asked

    • “How do you work with synchronous and asynchronous code in Playwright tests?”
    • “How do you run tests in parallel in Playwright?”

11. What are workers used for in Playwright?

    Asked in 3 of 109 interviews · last asked Oct 10 · Concept · Mid-level

    Show answer

    Workers in Playwright Test are separate processes that run tests in parallel to reduce total test time. Each worker runs its own browser instance. You can set the worker count to control how many run at once.

    • Test files run in parallel by default; tests within one file run sequentially unless configured otherwise.
    • Workers do not share in-memory variables.
    • Each test gets a fresh browser context by default, even when tests share a worker.
    • Too many workers can overload your machine or the application under test.

    What the interviewer checks: The interviewer is checking whether you understand parallel test execution, test isolation, and resource limits.

    Other ways it was asked

    • “What are Playwright workers?”
    • “What is Playwright used for?”

12. What are end-to-end tests?

    Asked in 3 of 109 interviews · last asked Sep 21 · Concept · Junior

    Show answer

    End-to-end tests check a complete user workflow across the application and its connected systems. I use them for critical flows, such as signing in or placing an order, in a production-like test environment. I keep the suite focused because these tests are slower and harder to maintain than unit tests.

    • Check the final business result, not just whether each action succeeds.
    • Use controlled test data and clean up changes so tests do not affect each other.
    • They complement unit and integration tests; they do not replace them.
    • They can run through a user interface or API, depending on the workflow.

    What the interviewer checks: The interviewer wants to know whether you understand full-workflow testing, when to use it, and its costs.

    Other ways it was asked

    • “What are end-to-end tests, and when should you use them?”
    • “How do you implement end-to-end tests in code?”

13. How would you investigate automated tests that pass locally but fail in CI or cloud environments?

    Asked in 3 of 109 interviews · last asked Sep 1 · Scenario · Mid-level

    Show answer

    I would inspect CI logs, screenshots, and error messages, then compare the local and CI setups. Using the same staging site does not mean browsers, permissions, network access, or test data are identical. I would reproduce the failure with CI settings and change one factor at a time to isolate the cause.

    • Compare code revisions, dependencies, browser versions, headless mode, screen size, and environment variables.
    • Check network access, credentials, permissions, and machine resources.
    • Look for shared test data, test order, and parallel execution conflicts.
    • Check for missing waits; use condition-based waits rather than fixed sleeps or retries that hide failures.

    What the interviewer checks: The interviewer is checking whether you use evidence to separate application bugs, test problems, and environment differences.

    Other ways it was asked

    • “A test passes locally but fails in CI or the cloud while running against staging in both environments. What could cause this?”
    • “If your automation is stable locally but fails intermittently in CI/CD, how would you systematically investigate whether the problem is code, script, or environment related?”
    • “What could be the reason why a Selenium test passes on your laptop, but it fails on Jenkins?”

14. What is the testing pyramid?

    Asked in 2 of 109 interviews · last asked Oct 8 · Concept · Junior

    Show answer

    The testing pyramid is a guide for balancing automated tests. It typically has many unit tests at the base, fewer integration tests in the middle, and very few end-to-end tests at the top. This balance gives fast feedback while keeping test costs and maintenance lower.

    • Unit tests check small pieces of code in isolation and usually run quickly.
    • Integration tests check whether components work together.
    • End-to-end tests check complete user flows but are usually slower and harder to maintain.
    • The pyramid is a guide, not a fixed ratio of tests.

    What the interviewer checks: The interviewer is checking whether you can balance test coverage, speed, and maintenance across test levels.

    Other ways it was asked

    • “What is the testing pyramid, and what levels does it typically include?”

15. How do you implement a data-driven approach in a test automation framework?

    Asked in 2 of 109 interviews · last asked Sep 18 · Tooling · Mid-level

    Show answer

    I keep test data separate from test logic, using files, databases, or data providers. I parameterize the test so it runs once for each dataset, with inputs and expected results. I validate the data, keep runs independent, and label each case so failures are easy to trace.

    • Use the framework’s parameterization feature to run the same test with different datasets.
    • Include expected results, valid inputs, invalid inputs, and boundary values.
    • Reset test state between cases so one dataset does not affect another.
    • Give each dataset a clear name or ID in test reports.

    What the interviewer checks: The interviewer checks whether you can reuse test logic while keeping data-driven tests independent and easy to debug.

    Other ways it was asked

    • “How do you implement data-driven testing in your automation framework?”

16. Tell me about a testing framework you built for a system that was difficult to test. What made your approach more effective than standard unit tests and mocks?

    Asked in 2 of 109 interviews · last asked Oct 17 · Behavioral · Senior

    Show answer

    I built an integration test framework for an order system with asynchronous messages. Retries, delays, and duplicate messages made it hard to test. It ran real services and a message broker in containers, injected failures, and checked order and payment records. Unlike unit tests with mocks, it exposed delivery and recovery bugs across service boundaries.

    • Tested duplicate delivery and service restarts to check that retries did not create extra charges.
    • Waited for expected results with a timeout instead of using fixed sleeps.
    • Isolated test data and captured logs to make failures easier to diagnose.
    • Kept fast unit tests; used integration tests for behavior that mocks could hide.

    What the interviewer checks: The interviewer wants to see how you chose realistic tests and defined correctness for a difficult system.

    Other ways it was asked

    • “Tell me about a testing framework you built for a difficult-to-test system. What made the system hard to test, and how did the framework validate correctness beyond basic unit tests?”

17. What is the difference between a selector and a locator in Playwright?

    Asked in 2 of 109 interviews · last asked Sep 8 · Concept · Mid-level

    Show answer

    A selector is a string that describes how to find an element, such as a CSS selector. A locator is a Playwright object used to find elements and interact with them. It finds the element again before each action and supports auto-waiting and retrying assertions.

    • Create locators with page.locator(selector) or helpers like page.getByRole().
    • A locator is not a saved DOM element; it resolves against the current page.
    • Actions such as click fail if the locator matches multiple elements.

    JavaScriptCopy

    const selector = '#submit';
    const locator = page.locator(selector);
    await locator.click();

    What the interviewer checks: The interviewer checks whether you understand how locators add reliable interaction beyond an element-matching string.

18. How do you upload a file in a Playwright test?

    Asked in 2 of 109 interviews · last asked Jun 22 · Write code · Junior

    Show answer

    I use locator.setInputFiles() to attach a file to the form's file input. Then I submit the form and check that the upload succeeded. If a button opens a file chooser, I start waiting for the filechooser event before clicking, then call chooser.setFiles().

    • Relative file paths start from the current working directory, not the test file's folder.
    • Pass an array of paths when the input supports multiple files.
    • Check the upload result, not just the selected filename.
    • Playwright sets files without controlling the operating system's file picker.

    JavaScriptCopy

    // tests/upload.spec.js; run: npx playwright test tests/upload.spec.js
    // Assumes this local form exists and tests/fixtures/photo.png is available.
    import { test, expect } from '@playwright/test';
    test('uploads an image', async ({ page }) => {
      await page.goto('http://localhost:3000/upload');
      await page.locator('input[type="file"]').setInputFiles('tests/fixtures/photo.png');
      await page.getByRole('button', { name: 'Upload', exact: true }).click();
      await expect(page.getByText('Upload complete', { exact: true })).toBeVisible();
    });

    What the interviewer checks: The interviewer checks whether you can select files reliably and verify that the application uploaded them.

    Other ways it was asked

    • “How would you write and run a Playwright test that uploads an image through a form?”
    • “How do you upload files in Playwright tests?”

19. What is Cypress?

    Asked in 2 of 109 interviews · last asked Sep 15 · Concept · Junior

    Show answer

    Cypress is a tool for testing web applications with JavaScript or TypeScript. I would use it for end-to-end tests in a browser and for component tests. It offers automatic waiting, retries for queries and assertions, and tools to debug failures.

    • Tests user actions and checks results in a real browser.
    • Supports end-to-end testing and testing individual UI components.
    • Automatic waiting reduces the need for fixed delays.
    • It is not designed to test native mobile or desktop apps.

    What the interviewer checks: The interviewer wants to know what Cypress tests and when you would choose it.

    Other ways it was asked

    • “When would you use Cypress?”

20. What are Selenium locators, and when would you use them?

    Asked in 2 of 109 interviews · last asked Oct 12 · Concept · Mid-level

    Show answer

    Selenium locators are rules used to find elements on a web page. I use them before clicking buttons, typing into fields, or checking results. I prefer stable, unique IDs or CSS selectors, and use XPath when element relationships make it useful.

    • Selenium supports ID, name, class name, tag name, link text, partial link text, CSS selector, and XPath.
    • Avoid fragile locators, such as absolute XPath paths that break when the page structure changes.
    • Finding an element does not mean it is ready for interaction; use explicit waits when needed.
    • Playwright offers role, label, text, and test ID locators; its actions automatically wait for relevant readiness checks.

    What the interviewer checks: The interviewer checks whether you can choose reliable locators and understand how they support browser interactions.

    Other ways it was asked

    • “What are Selenium locators, when would you use them, and how does Playwright locate elements?”
    • “Can you tell me what a locator is in Selenium?”

Related interview questions

• QA Engineer interview questions
• Software Engineer interview questions
• DevOps Engineer interview questions
• AI Engineer interview questions
• System Administrator interview questions
• Manual Testing interview questions
• API Testing interview questions
• Agile and Scrum interview questions
• Salesforce interview questions

How this list is made

Every question here was asked by a real interviewer in a real job interview that a candidate ran MeetAssist in. After the call, the interviewer's questions are pulled from the transcript. Practice sessions, tests, exams and anything that was not a job interview are dropped.

Questions are rewritten so they make sense on their own: names of people, employers and clients are removed, and speech-to-text mistakes are fixed. Small talk, logistics and questions about one candidate's own résumé are left out. Rephrasings of the same question are merged, and the count is the number of different interviews it came up in.

The interviews come from candidates who use MeetAssist, so they lean towards software, data and AI roles: the shares describe these interviews, not every Automation Testing interview. Answers to the most asked questions are written and checked by an editor; a "common mistake" is shown only when reviews of real answers in these interviews show it, with the count.

109 interviews, 59 candidates, Jan 2026 to Oct 2026. Updated every month with new interviews.