QA Engineer Interview Questions (2026) and How to Answer

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

1. 1.Tell me about a serious bug you caught before release.

   What they're really asking: Your instinct for where bugs hide, and how you communicate them.

   Answer outline (STAR)

   • SituationA release with a risky change and a deadline.
   • TaskFind what could hurt users before they did.
   • ActionExploratory testing around the risky area, then a clear report with steps and impact.
   • ResultWhat was prevented (data loss, a payment error) and the test you added.

   Full sample answer (fictional example)

   Two days before a release I ran exploratory tests around a new discount feature, which the plan marked as low risk. I applied two discount codes in two browser tabs at once and the order total went negative. I reported it with steps, a short video and the impact: customers could place orders at zero cost. The developer reproduced it in ten minutes and added a server-side check. I wrote an automated test for stacked discounts and added concurrent use to my exploratory checklist for any pricing change.

2. 2.Tell me about a flaky test suite you fixed.

   What they're really asking: Do you make automation trustworthy, or just rerun it until it passes?

   Answer outline (STAR)

   • SituationCI tests failing at random, so people ignored real failures.
   • TaskRestore the team's trust in the suite.
   • ActionTrack flaky tests, fix waits and test data, isolate tests, quarantine the worst.
   • ResultThe flaky rate before and after, and faster merges.

   Full sample answer (fictional example)

   Our suite of 600 UI tests failed randomly in about one run in three, so developers started ignoring red builds. I tracked each failure for two weeks and found most came from fixed sleeps and shared test accounts. I replaced sleeps with waits on specific conditions, gave each test its own data, and quarantined the 15 worst offenders in a separate job. Flaky runs fell from about 30 percent to under 3, merge times dropped by a third, and developers began trusting the build again.

3. 3.Describe a time a developer disagreed that something was a bug.

   What they're really asking: Can you argue for users with evidence and keep a good working relationship?

   Answer outline (STAR)

   • SituationBehaviour you saw as a defect and the developer saw as intended.
   • TaskSettle it on facts, not opinions.
   • ActionCheck the requirements, show the user impact, bring in the product owner.
   • ResultThe decision, and the requirement that became clearer.

   Full sample answer (fictional example)

   A developer said a search page that ignored accents was 'working as designed'. I didn't argue opinions. I checked the requirement, which said nothing, and then looked at support tickets: customers with accented names couldn't find themselves. I brought three tickets and a short recording to the product owner, who agreed it was a defect and set the priority. The developer fixed it in a day, and later asked me to review requirements for a similar feature before he started. I also wrote the missing line into the requirement.

4. 4.Tell me about a time you introduced test automation.

   What they're really asking: Can you plan automation that pays for itself?

   Answer outline (STAR)

   • SituationA team relying on slow manual regression testing.
   • TaskAutomate the right things first.
   • ActionPick high-value, stable flows, choose a framework, run it in CI and train the team.
   • ResultRegression time saved, and how often the team could release.

5. 5.Tell me about a bug that escaped to production.

   What they're really asking: Do you learn from misses without getting defensive?

   Answer outline (STAR)

   • SituationA defect users found after a release.
   • TaskUnderstand why testing missed it.
   • ActionTrace the root cause: a missing case, an environment difference or test data.
   • ResultThe test or process change that closed the gap.

6. 6.Tell me about working with a team that didn't value testing.

   What they're really asking: Can you win people over with results instead of rules?

   Answer outline (STAR)

   • SituationDevelopers who treated testing as someone else's job.
   • TaskBuild the habit without nagging.
   • ActionStart with one painful bug class, show its cost, pair on tests, offer small tools.
   • ResultChanges in behaviour, such as developers adding tests unprompted.

7. 7.Tell me about fixing unreliable test data or environments.

   What they're really asking: Do you attack the real cause of untrustworthy tests?

   Answer outline (STAR)

   • SituationTests failing because shared data changed or staging was down.
   • TaskMake test runs repeatable.
   • ActionCreate data per test, reset environments with scripts, containerise dependencies.
   • ResultFailure rate before and after, and the time people regained.

8. 8.Tell me about testing something you didn't fully understand.

   What they're really asking: How fast can you learn a domain well enough to test it?

   Answer outline (STAR)

   • SituationA payments, health or logistics feature with unfamiliar rules.
   • TaskTest it properly despite the gaps.
   • ActionInterview experts, read the specs, draw a model, test the boundaries.
   • ResultBugs found that a surface check would miss, and what you learned.

9. 9.Tell me about a release you recommended delaying.

   What they're really asking: Do you have the judgement to hold a line, with evidence?

   Answer outline (STAR)

   • SituationA release with an unresolved data-loss or security risk.
   • TaskPresent the risk so decision-makers can decide.
   • ActionQuantify who is affected, show evidence, offer options such as a partial release.
   • ResultThe decision made, and what followed.

   Full sample answer (fictional example)

   Before a payroll release I found that rounding differed by a cent between the preview and the final payslip for part-time workers. It affected about 4,000 people. I wrote up the evidence, listed who was affected, and gave the product owner three options: delay two days, release without the part-time feature, or release and correct later. I didn't say 'don't ship'; I made the trade-off easy to decide. She chose to release without that feature, and we fixed it the next week. Nobody got an incorrect payslip.

10. 10.Tell me about a test strategy you wrote.

    What they're really asking: Can you plan testing for a whole feature, not just run cases?

    Answer outline (STAR)

    • SituationA new product or large feature with no agreed approach.
    • TaskAgree what to test, how, and by whom.
    • ActionList risks, assign test levels, choose tools and environments, define exit criteria.
    • ResultHow the plan was used, and what it caught.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

1. 11.How would you test a login page?

   What they're really asking: A classic that shows how wide and how deep you think.

   Answer outline

   • Functional cases: valid and invalid credentials, lockout, password reset, remember me.
   • Security cases: injection attempts, brute-force protection, errors that don't reveal which field was wrong.
   • Also usability, accessibility, browsers and behaviour under load.

   Full sample answer (fictional example)

   I'd start with the functional cases: valid login, wrong password, unknown user, empty fields, password reset, remember me and lockout after repeated failures. Then security: the error message shouldn't reveal whether the email exists, injection attempts should fail, and brute-force protection should kick in. Then usability and accessibility: tab order, screen reader labels, password manager autofill. Finally compatibility across browsers and devices, and behaviour under load, such as many logins at once. I'd automate the main login path and keep the rest exploratory.

2. 12.What's the test pyramid, and does it still hold?

   What they're really asking: Do you know how to balance test types for speed and confidence?

   Answer outline

   • Many fast unit tests, fewer integration tests and a few slow end-to-end tests.
   • End-to-end tests catch integration bugs but are slow and prone to flakiness.
   • Some teams prefer more integration tests (the testing trophy); say what you'd choose and why.

   Full sample answer (fictional example)

   The pyramid says to have many fast unit tests, fewer integration tests and only a few slow end-to-end tests, because lower tests are cheaper, quicker and less flaky. End-to-end tests catch problems between components, but they take time to run and to maintain. It mostly holds, though I think the shape depends on the system. For a service with many integration points I'd add more integration tests, as in the testing trophy. What matters is that each risk is caught at the cheapest level that can catch it.

3. 13.How do you test an API?

   What they're really asking: API testing is now a core QA skill.

   Answer outline

   • Check status codes, response schemas, error handling and authentication.
   • Use tools such as Postman or REST Assured, and automate the checks in CI.
   • Cover edge cases: missing fields, large payloads and rate limits.

4. 14.How do you decide what to automate and what to test manually?

   What they're really asking: Judgement about the return on automation.

   Answer outline

   • Automate stable, repetitive, high-risk flows such as regression and smoke tests.
   • Keep exploratory and usability testing manual.
   • Don't automate features that still change every week.

5. 15.How do you handle waits and synchronisation in UI tests?

   What they're really asking: The most common cause of flaky tests.

   Answer outline

   • Avoid fixed sleeps; wait for a specific condition instead.
   • Use the framework's auto-waiting in Playwright or Cypress, or explicit waits in Selenium.
   • Keep tests independent, each with its own test data.

6. 16.What makes a good bug report?

   What they're really asking: Can a developer act on your report without asking you anything?

   Answer outline

   • A clear title, steps to reproduce, and the expected and actual results.
   • The environment, plus logs, screenshots or a short video.
   • The severity and the impact on users.

   Full sample answer (fictional example)

   A good bug report lets a developer act without asking me anything. It has a specific title, such as 'Checkout total shows zero when two coupons are applied', the exact steps to reproduce, the expected result and the actual result. I add the environment: browser, device, build and account type. A screenshot, video or log excerpt helps. Then severity and impact: who is affected and whether there's a workaround. I check for duplicates first, and I keep each report to one problem, so it can be fixed and verified on its own.

7. 17.How do you test something with no written requirements?

   What they're really asking: Can you work from risk and conversation when the specs are thin?

   Answer outline

   • Ask the product owner and developers how it's meant to behave.
   • Run exploratory sessions with a charter, and write down your assumptions.
   • Turn what you learn into acceptance criteria for next time.

8. 18.What is the difference between smoke, sanity and regression testing?

   What they're really asking: Do you use testing terms precisely and know when to run each?

   Answer outline

   • Smoke tests check the build is stable enough to test: a quick pass over critical paths.
   • Sanity tests check that one change or fix works, in a narrow scope.
   • Regression tests check that old behaviour still works, before every release.

9. 19.Explain boundary value analysis and equivalence partitioning with an example.

   What they're really asking: A basic design technique: can you cover a lot with few cases?

   Answer outline

   • Split inputs into groups that behave alike, and test one from each group.
   • Bugs cluster at the edges, so test just below, at and above each boundary.
   • For an age field of 18 to 65, try 17, 18, 65 and 66, plus a typical value.

10. 20.How do you structure automated UI tests so they stay maintainable?

    What they're really asking: Do your suites survive a UI redesign?

    Answer outline

    • Use page objects or a similar layer, so selectors live in one place.
    • Keep tests independent with their own data, and use stable test IDs, not CSS paths.
    • Keep each test short and focused on one behaviour, and review test code like product code.

11. 21.How do you approach performance testing, and what do you measure?

    What they're really asking: Do you know the kinds of load test and what the numbers mean?

    Answer outline

    • Load, stress and soak tests ask different questions: normal use, breaking point, long running.
    • Measure response time percentiles, throughput, error rate and resource use, not averages.
    • Use realistic data and traffic mixes on a production-like environment.

12. 22.How would you test a checkout and payment flow?

    What they're really asking: A high-stakes feature: can you cover money, errors and security?

    Answer outline

    • Cover happy paths, declined cards, timeouts, double clicks and rounding of tax and currency.
    • Check orders, payments and emails stay consistent when a step fails midway.
    • Use sandbox providers, verify no card data is logged, and test several browsers.

Take-home or live exercise: tips

QA loops often include a test-design exercise on a sample feature, and an automation task, such as a few UI or API tests in Playwright, Selenium or Postman.

• Think aloud while listing risks, and group test ideas by area before writing cases.
• Write stable tests: waits on conditions, independent data and clear assertion messages.
• Say what you would not automate and why; it shows judgement.

Skills employers test for

Technical rounds follow the job ad. These skills are named most often in the 506 newest QA engineer job ads we analysed (out of 2,611 live postings), shown as the share of ads that mention each. Expect questions on the top few.

1. 1Unit testing47%
2. 2Test plans42%
3. 3Python35%
4. 4Agile28%
5. 5CI/CD28%
6. 6Process improvement23%
7. 7Playwright16%
8. 8Jira16%

Full list: QA Engineer resume keywords.

From live job ads · computed November 2, 2026 · refreshed daily

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

1. 23.Release is tomorrow and you've found a medium-severity bug. What do you do?

   What they're really asking: Can you weigh risk calmly instead of blocking or waving things through?

   Answer outline

   • Assess the impact: how many users, whether there's a workaround, any risk to data.
   • Report it to the product owner with a recommendation.
   • The call isn't yours alone: record the decision and test the fix when it lands.

   Full sample answer (fictional example)

   I'd first assess the impact: how many users, whether there's a workaround, and any risk to data or money. Then I'd report it to the product owner with a recommendation, such as releasing with a known-issue note or holding for a fix, depending on severity. The decision isn't mine alone, and I'd record it. If the team ships, I'd confirm monitoring is in place for that area and test the fix as soon as it lands. If the bug corrupts data, my recommendation would be to hold.

2. 24.Developers say QA slows them down. How do you respond?

   What they're really asking: Do you treat quality as a team job, or as a gate at the end?

   Answer outline

   • Move testing earlier: review stories, pair on tests, grow unit test coverage.
   • Make the automated checks in CI fast.
   • Measure cycle time and show where the waiting really happens.

   Full sample answer (fictional example)

   I'd take it seriously and look for where the waiting really happens. I'd ask developers what slows them: slow CI, late-found bugs, unclear acceptance criteria. Then I'd move testing earlier: review stories before development, pair on unit tests, and agree acceptance criteria up front. I'd make automated checks faster by running them in parallel and pruning duplicates. And I'd measure cycle time and escaped defects, so we can see whether we're getting faster and safer instead of arguing from feelings. Quality should be a team habit, not a gate at the end.

3. 25.You have one day to test a big change. How do you prioritise?

   What they're really asking: When you can't test everything, do you know what to test first?

   Answer outline

   • Rank areas by user impact and by how likely they are to break.
   • Test the critical paths and the changed code first.
   • Report clearly what was and wasn't tested.

4. 26.The CI test suite takes 90 minutes. What would you change?

   What they're really asking: An engineering mindset applied to testing.

   Answer outline

   • Profile the slowest tests, run in parallel and remove duplicates.
   • Run a fast smoke set on every commit and the full suite nightly.
   • Push checks down to the unit or API level where possible.

5. 27.The product owner asks you to skip regression testing to hit the date. How do you respond?

   What they're really asking: Can you hold a line on risk without being a blocker?

   Answer outline

   • Explain what the skipped testing protects, in terms of customers and revenue.
   • Offer a risk-based option: a focused regression on the critical flows only.
   • If the call is to skip, get it recorded and watch closely after release.

   Full sample answer (fictional example)

   I'd ask what the date protects and explain what the regression suite protects: usually the customer's core flows, such as login, search and payment. Then I'd offer a middle path: a focused regression on the five most critical flows, which takes a few hours instead of two days, plus extra monitoring after release. If the product owner still decides to skip, I'd make sure the decision is written down, and I'd be ready to test fast if something breaks. I wouldn't simply refuse; I'd make the risk visible and the options clear.

6. 28.A customer reports a bug you can't reproduce. What do you do?

   What they're really asking: Persistence and method with problems you can't see.

   Answer outline

   • Collect the steps, account, device, version and time, and check logs for that session.
   • Match the data, settings and network conditions, not just the steps.
   • If stuck, add logging or monitoring and tell the customer what you're doing.

7. 29.You join a team with no QA process. Where do you start?

   What they're really asking: Can you introduce quality practices without heavy process?

   Answer outline

   • Listen first: where do bugs hurt most, and what is already tested informally?
   • Start small: a smoke suite for critical flows, a bug template, a release checklist.
   • Show results within a month, then grow the practice.

8. 30.An automated test fails only in CI, never on your machine. What do you do?

   What they're really asking: Do you diagnose environment-dependent failures methodically?

   Answer outline

   • Compare the environments: versions, timing, parallelism, data and screen size.
   • Run the test in the CI container locally and capture logs, screenshots or traces.
   • Fix the cause, such as a race or shared data, rather than adding retries.

Red flags to avoid in your answers

Each one is quick to fix before the day.

1. Describing testing as finding bugs and nothing else.

   Talk about preventing defects: reviewing requirements, analysing risk and giving developers fast feedback.

2. Quoting the number of test cases or bugs logged as an achievement.

   Talk about risk covered and the defects that mattered, not volume.

3. Blaming developers when a bug escapes.

   Describe what the test process missed and the change you made.

4. Saying you automate everything.

   Explain what you'd automate, what stays manual, and how you judge the return.

How to prepare for a QA engineer interview in 7 days

An hour or two a day is enough; the order matters more than the length.

1. 1

   Day 1: List the risks

   Note the test tools, languages and CI in the ad, then use the company's product and write down five risks.

2. 2

   Day 2: Test design

   Practise test ideas for a login, a search and a checkout using boundaries and partitions, five minutes each.

3. 3

   Day 3: Automation

   Write a small suite in the company's framework: two UI tests and two API tests, independent and stable.

4. 4

   Day 4: Process questions

   Prepare answers on the pyramid, flaky tests, CI speed and release decisions, each with an example of yours.

5. 5

   Day 5: Stories

   Write STAR stories on a bug caught, a bug that escaped, a disagreement and an automation win.

6. 6

   Day 6: Mock

   Do a mock with a friend: test a sample feature aloud for 20 minutes, then answer three behavioural questions.

7. 7

   Day 7: Review and rest

   Reread your bug reports and test plans, prepare three questions about release criteria, and rest.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

1. What's the ratio of developers to QA engineers, and who writes the automated tests?
2. Which test frameworks and CI tools do you use?
3. How do you decide that a release is ready?
4. How many bugs reach production, and how are they tracked?
5. Is QA involved when the user stories are written?

Preparation tips

• Practise writing a small automated suite in the company's framework and language.
• Have a way of sketching a test plan for any feature in five minutes: risks, levels, data, environments.
• Know the basics of HTTP, SQL and Git; QA engineers use all three every day.
• Bring real examples of bugs you found and how you reported them.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.