QA interviews in 2026 go past manual testing: expect SQL, API testing, Git, one automation tool and at least one question about AI. Here are the 25 that come up most, with what the interviewer is checking and an answer you can say in under a minute. Learn the idea, then say it in your own words with one example from your own project.
Fundamentals
1. What is the difference between verification and validation?
Checking: an example, not a definition.
Verification checks requirements, designs and code against the spec, by review. Validation runs the software to check it meets what the user needs. Reviewing acceptance criteria is verification; testing login is validation.
2. Smoke, sanity and regression testing.
Checking: what gets automated first.
Smoke is a quick check that a new build's critical flows work. Sanity is a narrow check on one area after a fix. Regression re-runs existing tests to confirm nothing else broke, and it is what teams automate first.
3. Severity versus priority, with examples.
Checking: two examples, ready.
Severity is how badly the bug hits the system; priority is how soon it must be fixed. High severity, low priority: a crash on a rarely used admin report. Low severity, high priority: the company name misspelt on the home page.
4. What are functional and non-functional testing?
Checking: concrete cases, both sides.
Functional testing checks what the system does against requirements, such as login with a wrong password. Non-functional testing checks how well: speed under load, security, usability, browsers and devices.
5. What makes a good test case?
Checking: proof you have written some.
An ID, a clear title, preconditions, test data, numbered steps and one expected result that someone else can check without asking me. It tests one thing and links to a requirement.
6. What goes in a bug report?
Checking: can the developer reproduce it?
What broke and where in one line, environment, steps to reproduce, expected and actual result, severity and priority, and a screenshot or video with logs. "Pay button stays disabled after a valid UPI ID (Chrome, Android 14)" is a summary. "Payment not working" is not.
Test design and SDLC
7. SDLC and STLC: when does testing start?
Checking: shift-left thinking.
SDLC is the software's whole life, requirements to maintenance. STLC is the testing part: analysis, planning, design, environment setup, execution, closure. Testing starts with the requirements; a gap found in review is the cheapest bug you will fix.
8. An age field accepts 18 to 60. What do you test?
Checking: partitions and boundaries together.
Equivalence partitioning gives three groups, below 18, 18 to 60 and above 60, one value each. Boundary value analysis adds the edges: 17, 18, 19 and 59, 60, 61. Nine tests instead of dozens.
9. When do you use a decision table?
Checking: multi-condition logic.
When the outcome depends on several conditions at once. A loan approved only if salary clears a set amount and the credit score is at least 700: two conditions, four combinations, four tests, including the one nobody thought about.
10. Write test scenarios for a login page.
Checking: structure, not volume.
I group them. Positive: valid login, remember me. Negative: wrong password, unregistered email, empty fields. Edge: spaces around the email, password case, lockout after repeated failures. Security: masked password, an error that does not say which field was wrong. Then browsers and mobile.
11. Explain the bug life cycle.
Checking: a real Jira workflow.
New, assigned, open, fixed, ready for retest, verified, closed, with side paths for rejected, duplicate, deferred and reopened. Exact Jira statuses depend on the team's workflow; I say which one my project used.
API and SQL
12. HTTP methods and status codes.
Checking: 401 against 403.
GET reads, POST creates, PUT replaces, PATCH updates part, DELETE removes. 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 server error. 401 means not authenticated; 403 means authenticated but not allowed.
13. What do you check in an API response?
Checking: you look past the status code.
Status code, response time, the body (required fields, types, values) and headers such as Content-Type. Then negative cases: missing fields, wrong types, an expired token, a duplicate create. And after a POST, a GET should show the new record.
14. Write a query for the second highest salary.
Checking: duplicate salaries.
SELECT MAX(salary) FROM employee WHERE salary < (SELECT MAX(salary) FROM employee); It handles two people on the top salary. If you use ORDER BY with OFFSET instead, add DISTINCT, or duplicates give you the wrong row.
15. INNER JOIN versus LEFT JOIN.
Checking: a testing use.
INNER JOIN returns only rows that match in both tables. LEFT JOIN returns every left-table row, with NULLs where the right has no match. Testing use: LEFT JOIN payments onto orders and keep rows where the payment id is NULL to find unpaid orders.
Automation with Playwright or Selenium
16. Why Playwright? Is Selenium finished?
Checking: balance. "Selenium is dead" is a red flag.
Playwright: one API for Chromium, Firefox and WebKit, auto-waiting, retrying assertions, parallel runs, a trace viewer and API testing. Selenium 4 follows the W3C WebDriver standard, has bindings in five languages and runs most existing suites. New project, Playwright; existing Selenium framework, keep and improve it.
17. How does waiting work in Playwright versus Selenium?
Checking: why fixed sleeps are flaky.
Playwright checks before each action that the element is visible, stable, enabled and receiving events, and retries until it is. Selenium needs WebDriverWait with expected conditions for that. A fixed sleep is wrong in both: too short fails, too long crawls.
18. Which locators do you prefer?
Checking: resilience to UI change.
User-facing locators first: getByRole with an accessible name, then getByLabel, getByText, and getByTestId when the team adds test IDs. They find elements the way users do, so they survive CSS and layout changes. Selenium: ID, then CSS, then relative locators. XPath last.
19. A test passes locally but fails in CI. What do you do?
Checking: the trace viewer; no hiding flaky tests.
I open the trace. With trace: 'on-first-retry' in the config, a retried test records every action, DOM snapshot, network call and console log. The cause is usually a timing assumption, shared test data or an environment difference. I fix the cause, not the symptom.
20. How do you structure an automation framework?
Checking: Page Object Model plus fixtures.
Page objects hold each screen's locators and actions, so a UI change is a one-file fix. Fixtures, built with test.extend in Playwright, hand each test what it needs, such as a logged-in page, and clean up afterwards. Config holds browsers, base URL and retries.
21. Running the suite in CI, and a 40-minute suite.
Checking: the test pyramid, not only the tool.
A GitHub Actions workflow on push and pull request: check out, set up Node, npm ci, npx playwright install --with-deps, npx playwright test, upload the report as an artifact. For 40 minutes: more workers, sharding, a saved storageState instead of logging in per test, business rules moved to API tests.
AI in testing and behaviour
22. How do you use AI tools in testing?
Checking: judgement and data safety.
For the slow parts: scenarios from a user story, test data, a first draft of a test or SQL query, explaining an error. I review everything, because the tool invents selectors and misses edge cases, and I never paste company code or customer data into an unapproved tool.
23. Have you used Playwright's test agents or MCP server?
Checking: you keep up, and still own quality.
Playwright 1.56 added three agents, set up with npx playwright init-agents and run through an AI coding assistant: a planner that writes a test plan, a generator that turns it into tests, a healer that tries to fix failures. The MCP server lets an assistant drive a real browser. I still decide what to test and review every change.
24. A critical bug an hour before release. What do you do?
Checking: ownership under pressure.
Reproduce it, capture evidence, log it with the exact user impact, and tell the QA lead and product owner straight away. The call is theirs: delay, hotfix, or ship with a known issue and a workaround. I make sure they decide with full information.
25. No work experience. Why should we hire you?
Checking: proof over adjectives.
I have done the work at a smaller scale: test cases, bug reports, automated tests and a CI pipeline on a real project, all on my GitHub. If it helps, I can walk you through the repository now.
What to do next
- The QA Interview Kit has 50 questions across 11 topics, with model answers and code you can explain. Ask for it on WhatsApp.
- From zero: the QA Career Track, manual to Playwright and AI testing in four months, with mock interviews and placement assistance. Already a tester: NextGen SDET (Playwright), Playwright, TypeScript and AI in two months.
- Not sure which fits? Talk to a counsellor.
- We also run a free Playwright + AI masterclass, where you write, run and fix an automated test with AI in three hours.