QA mock interview: manual and automation
This QA mock interview is for manual and automation testers preparing for junior, middle or senior roles. The AI interviewer asks the QA interview questions real teams ask, from testing theory and test design to API testing, SQL and automation frameworks, and scores every spoken answer on technical accuracy, completeness and clarity. Pick QA as the technology or upload your resume or a job post to get QA automation interview questions for a specific role.
What the AI interviewer asks about
Testing theory and test levels
Verification vs validation, the testing principles, unit, integration, system and acceptance levels, and the difference between smoke, sanity and regression testing.
Test design techniques
Equivalence partitioning, boundary value analysis, decision tables, state transition and pairwise testing. Expect to design test cases for a login form or a discount rule out loud.
Bug lifecycle and reporting
Bug statuses from New to Closed or Reopened, severity vs priority, and what makes a bug report reproducible: steps, expected and actual results, environment and evidence.
API testing
HTTP methods and status codes, idempotency, REST vs GraphQL basics, authentication with tokens, and checking contracts and negative cases in Postman or code.
SQL for QA
SELECT with WHERE, GROUP BY and HAVING, INNER vs LEFT JOIN, and using queries to verify that the UI or API actually wrote the right data.
Automation frameworks
Selenium WebDriver, Playwright and Cypress with Java, Python or JavaScript: locators, waits, Page Object Model, test runners and how to fight flaky tests.
CI and test strategy
The test pyramid, running suites in CI on every pull request, parallel runs, reporting, and deciding what to automate and what to keep manual.
Web and mobile specifics
Cross-browser and responsive checks, cookies and caching, and on mobile: interruptions, permissions, poor network, device fragmentation and app updates.
QA interview questions by level
Junior
What is the difference between severity and priority?
What a strong answer covers:Severity describes how badly the bug affects the system, priority describes how soon it must be fixed from a business point of view. They are set independently: a typo in the company name on the home page is low severity but high priority, while a crash in a rarely used admin report can be high severity but lower priority. Mention that QA usually sets severity and the product owner or lead often has the final say on priority.
What is the difference between smoke, sanity and regression testing?
What a strong answer covers:Smoke testing is a quick, broad check that a new build is stable enough to test at all: the app starts, login works, key flows open. Sanity testing is a narrow check that a specific fix or change works as expected. Regression testing verifies that existing functionality still works after changes, and it is the main candidate for automation because it repeats every release.
How would you apply boundary value analysis to a field that accepts ages 18 to 60?
What a strong answer covers:First split the input into equivalence classes: below 18, 18 to 60, above 60, plus invalid input like letters or an empty value. Then test at the edges, where bugs cluster: 17, 18, 60 and 61, optionally 19 and 59 for the three-value variant. This gives high coverage with a handful of test cases instead of checking every number.
What should a good bug report contain?
What a strong answer covers:A short, specific title, clear steps to reproduce, expected and actual results, and the environment: build or version, browser or device, OS, test data. Attach evidence such as a screenshot, video, logs or the failing API request, and set severity. The test is simple: another person must be able to reproduce the bug without asking you anything.
What is the difference between verification and validation?
What a strong answer covers:Verification asks "are we building the product right?": checking that the work matches the requirements and specifications, for example through reviews of requirements, design and code. Validation asks "are we building the right product?": checking that the result actually meets user needs, usually by testing the working software. A short way to say it: verification against the spec, validation against the user.
Middle
Which HTTP methods are idempotent and why does it matter for API testing?
What a strong answer covers:GET, PUT, DELETE, HEAD and OPTIONS are idempotent: repeating the same request leaves the server in the same state. POST is not, and PATCH is not guaranteed to be. In testing this means you send the same PUT or DELETE twice and check that nothing extra happens, and for POST you check how the API handles duplicates, for example with an idempotency key or a unique constraint.
What is the difference between 401 and 403 status codes, and how would you test authorization?
What a strong answer covers:401 Unauthorized means the request has no valid authentication: a missing, expired or broken token. 403 Forbidden means the user is authenticated but has no rights for this resource. To test authorization, call each endpoint without a token, with an expired token, and with a token of a user who has a different role or owns different data, and check that one user cannot read or change another user's resources by changing an ID.
What is the difference between INNER JOIN and LEFT JOIN, and when would QA use it?
What a strong answer covers:INNER JOIN returns only rows that have a match in both tables, LEFT JOIN returns all rows from the left table and NULLs where there is no match on the right. QA often uses LEFT JOIN with WHERE right_table.id IS NULL to find orphaned or missing data, for example users without a profile or orders without payments. It is a common way to verify data integrity after a migration or a backend change.
What causes flaky tests and how do you deal with them?
What a strong answer covers:Typical causes are timing issues and hard-coded sleeps, shared or leftover test data, dependence on test order, unstable environments and third-party services, and fragile locators. Fix the root cause: use explicit or built-in auto-waiting, isolate test data per test, mock unstable dependencies and use stable locators like data-testid. Retries can reduce noise in CI, but flaky tests should be tracked and quarantined, not silently retried forever.
What is the Page Object Model and what are its downsides?
What a strong answer covers:Page Object Model puts locators and page actions into classes, so tests read as business steps and a UI change is fixed in one place instead of in every test. Its downsides are large "god" page objects, assertions leaking into page classes and extra layers for simple pages. Good answers mention keeping assertions in tests, splitting reusable components, and that in Playwright or Cypress lighter patterns like fixtures or custom commands are also common.
Senior
How would you build a test strategy for a new product from scratch?
What a strong answer covers:Start from risks and business priorities: which flows bring money or would hurt users most if broken. Define test levels and the split between unit, API and UI tests, environments and test data, entry and exit criteria, and which checks run in CI on every change versus before release. Explain how you would agree on this with developers and product, and how you would measure whether the strategy works, for example by escaped defects and test feedback time.
How do you decide what to automate and what to keep manual?
What a strong answer covers:Automate checks that are repeated often, stable, critical for the business and have a clear expected result: regression, smoke, API contracts and data-heavy scenarios. Keep manual exploratory testing, usability, one-off checks and features whose UI still changes every sprint. Also push checks down the pyramid: if something can be verified with a unit or API test, do not cover it with a slow end-to-end UI test.
Your end-to-end suite takes 90 minutes in CI. How would you speed it up?
What a strong answer covers:First measure: find the slowest and most failing tests and remove duplicates of what is already covered at API or unit level. Then run tests in parallel with isolated data, set up state through API calls or database seeding instead of clicking through the UI, and reuse authentication state. Finally split the pipeline: a fast smoke set on every pull request and the full regression nightly or before release.
How would you test a REST API that other teams depend on?
What a strong answer covers:Cover functional cases, negative cases and validation, authorization by role, and error formats. Protect the contract with schema checks or consumer-driven contract tests such as Pact, so a breaking change fails in CI before it reaches other teams. Add checks for backward compatibility and versioning, plus basic performance tests on key endpoints.
What QA metrics do you find useful, and which do you avoid?
What a strong answer covers:Useful ones show product quality and team speed: escaped defects found in production, time from commit to test feedback, flaky test rate and coverage of critical user flows. Raw counts like number of test cases or bugs found per tester are easy to game and say little about quality. A strong answer explains that metrics should drive decisions, for example which area needs more tests, not rank people.
How the QA mock interview works
- Pick QA (and any other technologies from your stack), your level and the interview language: English, Ukrainian or Russian. Or upload your resume and a job description.
- Answer each question out loud, the way you would with a real interviewer.
- Get a score for every answer on technical accuracy, completeness and clarity, plus a report with your weak spots.
How to answer QA interview questions out loud
- →For test design questions, name the technique first, then list concrete values: "equivalence classes are below 18, 18–60 and above 60; boundaries are 17, 18, 60 and 61."
- →When asked to test an object like a login form, structure the answer: positive cases, negative cases, boundaries, security, UI and usability. Structure scores better than a long random list.
- →Explain bugs and reports through a real example from your work: what you found, how you reproduced it and what severity you set.
- →For automation questions, say which stack you use (for example Playwright with TypeScript or Selenium with Java) and why, instead of describing tools in general.
- →On strategy questions, talk about risks and trade-offs: what you would not test and why matters as much as what you would.
FAQ
Does the QA mock interview cover both manual and automation testing?
Yes. Questions cover testing theory, test design, bug reporting, API testing and SQL, and for automation roles also frameworks, CI and test strategy. To focus on a specific role, upload your resume or a job description and the questions will follow it.
Can I choose Java or Python for automation questions?
Yes. Select QA together with the language you automate in, or upload a job post that names your stack, for example Selenium with Java or Playwright with Python. The interviewer then asks about that combination.
Can I take the interview in Ukrainian?
Yes. You can choose English, Ukrainian or Russian as the interview language. You can practice in Ukrainian first and then repeat the interview in English before calls with international clients.
Will I need to write code?
No. Questions are verbal and you answer by voice, there is no live coding editor. You explain how you would design tests, structure a framework or debug a flaky test, as you would in a technical interview call.