Top QA Interview Questions (and How to Answer Them)

QA interviews follow a pattern. Whether it’s a fresher role, a manual tester job or a QA engineer position with some automation, the same groups of questions come up again and again. This guide covers the questions you’re most likely to hear, with sample answers you can adapt, and tells you what the interviewer is actually checking with each one.

The short answer: the most common QA interview questions fall into six groups:

1. Testing fundamentals: SDLC vs STLC, verification vs validation, test levels and test types.
2. Bugs and defects: severity vs priority, the defect life cycle, writing a good bug report.
3. Test design: test cases vs test scenarios, boundary value analysis, equivalence partitioning.
4. Process and Agile: where QA fits in a sprint, regression testing, entry and exit criteria.
5. Automation, APIs and tools: what to automate, Selenium or Playwright basics, Postman, SQL.
6. Scenarios and behaviour: “how would you test this?”, conflicts with developers, release pressure.

Prepare a crisp answer for each group and practise two or three “how would you test X” questions out loud. That covers most of what a QA interview will throw at you.

What QA interviewers are really looking for

Before the questions, it helps to know what’s being scored. Across most companies, a QA interviewer is checking four things:

• Do you understand the basics? Can you explain testing terms clearly without reciting a textbook definition?
• Do you think like a tester? When shown a feature, do you naturally ask “how could this break?” and think of edge cases?
• Can you communicate? A tester’s output is mostly writing: bug reports, test cases, status updates. Clear answers signal clear reports.
• Will you work well with developers? QA sits between developers, product and users. Interviewers want someone firm about quality but not combative.

Keep these four in mind. A short answer that shows structured thinking beats a long answer that lists every term you’ve memorised.

Testing fundamentals questions

1. What is software testing, and why is it needed?

Sample answer: “Software testing is checking that a product does what it’s supposed to do and finding where it doesn’t, before users do. It’s needed because bugs are cheaper to fix the earlier they’re found, and because a product can work technically but still fail users if it’s confusing, slow or insecure. Testing also gives the team confidence to release.”

What they’re checking: that you see testing as reducing risk, not just finding bugs. If you want a deeper refresher, read what is software testing.

2. What is the difference between SDLC and STLC?

Sample answer: “SDLC, the software development life cycle, covers the whole process of building software: requirements, design, development, testing, deployment and maintenance. STLC, the software testing life cycle, is the testing part in detail: requirement analysis, test planning, test case design, environment setup, test execution and test closure. STLC runs inside SDLC.”

3. What is the difference between verification and validation?

Sample answer: “Verification asks ‘are we building the product right?’ It checks documents, designs and code against the spec, often through reviews and walkthroughs, without running the software. Validation asks ‘are we building the right product?’ It runs the software to check it meets the user’s actual needs.”

A memorable way to say it: verification is checking the recipe, validation is tasting the dish.

4. What are the levels of testing?

Level	What it tests	Who usually does it
Unit testing	One function or component in isolation	Developers
Integration testing	How modules work together (for example, the app and its database)	Developers and testers
System testing	The complete product end to end	QA team
Acceptance testing (UAT)	Whether it meets business needs	Users, clients or product owners

5. What is the difference between functional and non-functional testing?

Sample answer: “Functional testing checks what the system does: does login work, does the cart total add up, does the search return the right results? Non-functional testing checks how well it does it: performance, load, security, usability, accessibility and compatibility.”

6. What is the difference between black-box, white-box and grey-box testing?

• Black-box: you test inputs and outputs without seeing the code. Most manual and functional testing works this way.
• White-box: you test with knowledge of the code, such as making sure every branch of an if statement runs. Usually done by developers or SDETs.
• Grey-box: a mix. You know some internals, such as the database schema or API contract, and use that to design better black-box tests.

7. What are smoke testing and sanity testing?

Sample answer: “Smoke testing is a quick, broad check on a new build to see if the critical paths work at all: can you open the app, log in, reach the main screens? If it fails, the build goes back without deeper testing. Sanity testing is a narrow, focused check after a small change or bug fix to confirm that specific area works before you spend time on full regression.”

8. What is regression testing?

Sample answer: “Regression testing re-runs existing tests after a change to make sure nothing that used to work is now broken. It’s the best candidate for automation because it’s repeated every release. When time is short, I prioritise regression around the changed area and the most-used user flows.”

9. What is exploratory testing?

Sample answer: “Exploratory testing is testing without pre-written scripts: you learn the product, design tests and run them at the same time, guided by curiosity and risk. It’s great at finding bugs that scripted tests miss. I time-box it, for example a 45-minute session with a goal like ‘explore checkout with unusual addresses’, and take notes so the findings can be reproduced.”

Bug and defect questions

10. What is the difference between severity and priority?

This is probably the single most-asked QA question, so have examples ready.

Sample answer: “Severity is how much a bug affects the system. Priority is how urgently it needs to be fixed. They’re often related but not always.”

Example	Severity	Priority
The company logo is misspelled on the home page	Low	High
The app crashes when exporting a yearly report used once a year	High	Medium or low
Payment fails for every user	High	High
A tooltip has a small typo on a settings page	Low	Low

“Testers usually set severity because it’s a technical judgement. Product owners or leads set priority because it depends on business impact and timing.”

11. Explain the defect (bug) life cycle.

Sample answer: “A bug typically moves through these states: New when it’s logged, Assigned to a developer, Open while they work on it, Fixed once they’ve changed the code, Retest when it comes back to QA, then Closed if it passes or Reopened if it doesn’t. Along the way it can also be marked Rejected (not a bug), Duplicate, or Deferred (a real bug that’ll be fixed in a later release).”

Draw it if you’re on a whiteboard. Interviewers like seeing the reopen loop.

12. What makes a good bug report?

Sample answer: “A good bug report lets someone reproduce the bug without asking me anything. It has a clear title that names the problem and where it happens, the environment (build, browser, device), numbered steps to reproduce, expected result, actual result, severity, and evidence like a screenshot, video or logs.”

Weak title: “Login not working.” Strong title: “Login fails with ‘Server error’ for emails containing a plus sign (Chrome 129, staging build 4.2.1).”

13. What do you do if a developer says your bug is “not a bug”?

Sample answer: “First, I make sure I can reproduce it and re-read the requirement. If the requirement supports me, I show the developer the steps and the spec side by side. If the requirement is unclear, it’s not really our argument to settle, so I bring in the product owner to decide the expected behaviour and document the decision. Either way I keep it about the product, not about who’s right.”

14. What do you do if a bug can’t be reproduced?

Sample answer: “I still log it, with everything I know: exact time, environment, account used, logs, screenshots and what I was doing just before. Then I try to vary the conditions: different data, browser, network speed, user role. Intermittent bugs often turn out to be timing, caching or data-specific issues. I mark it clearly as intermittent so it isn’t dismissed.”

Test design questions

15. What is the difference between a test case and a test scenario?

Sample answer: “A test scenario is a high-level thing to test, like ‘verify a user can reset their password’. A test case is a detailed, step-by-step check under that scenario, with preconditions, test data, steps and an expected result, like ‘reset password with a registered email and confirm the reset link arrives within two minutes’. One scenario usually has several test cases.”

16. What goes into a test case?

A standard test case includes:

• Test case ID and title
• Preconditions (for example, “user is registered and logged out”)
• Test data
• Steps
• Expected result
• Actual result and status (pass, fail, blocked)
• Priority and a link to the requirement it covers

17. What is boundary value analysis?

Sample answer: “Bugs cluster at the edges of input ranges, so boundary value analysis tests values at and around each limit. If an age field accepts 18 to 60, I’d test 17, 18, 19, 59, 60 and 61.”

18. What is equivalence partitioning?

Sample answer: “It splits inputs into groups that the system should treat the same way, then tests one value from each group instead of every possible value. For an 18 to 60 age field, the partitions are below 18 (invalid), 18 to 60 (valid) and above 60 (invalid), plus non-numbers and empty input. It’s usually used together with boundary value analysis.”

19. What is a traceability matrix?

Sample answer: “A requirements traceability matrix maps each requirement to the test cases that cover it. It shows whether every requirement is tested and, when a requirement changes, which tests need updating.”

Process and Agile questions

20. What is the role of QA in an Agile team?

Sample answer: “In Agile, QA is involved from the start of each sprint, not only at the end. I help refine user stories and acceptance criteria, ask edge-case questions in planning, write tests while development happens, test stories as soon as they’re ready, and keep the regression suite healthy. The goal is that a story isn’t ‘done’ until it’s tested.”

21. What are entry and exit criteria?

Sample answer: “Entry criteria are the conditions that must be true before testing starts, like a stable build deployed to the test environment and approved requirements. Exit criteria define when testing is finished, like all high-priority test cases executed, no open critical bugs, and an agreed pass rate.”

22. What is shift-left testing?

Sample answer: “Shift-left means testing earlier in the process: reviewing requirements, writing tests alongside code, and running automated checks on every commit. Finding a requirement gap in planning costs far less than finding it in production.”

23. When do you stop testing?

Sample answer: “You can’t test everything, so stopping is a risk decision. I stop when the exit criteria are met, the critical and high-risk areas are covered, the bug discovery rate has dropped off, and the team agrees the remaining risk is acceptable. Deadlines also matter, and in that case I make the untested risks visible rather than hiding them.”

Automation, API and tools questions

24. What should you automate, and what shouldn’t you?

Automate: regression tests, smoke tests, tests run on many data sets, stable features, and API checks.

Keep manual: exploratory testing, usability and look-and-feel checks, features that change every sprint, and one-off tests.

Sample answer: “I automate things that are repeated, stable and high-value, and keep humans on things that need judgement. A good rule is that if a test will run more than a handful of times and the feature isn’t changing weekly, it’s a candidate.”

25. What is the test automation pyramid?

Sample answer: “It’s a guide for balancing automated tests: lots of fast unit tests at the bottom, fewer integration and API tests in the middle, and a small number of slow UI end-to-end tests at the top. Teams that invert it, with mostly UI tests, end up with slow, flaky suites.”

26. What is a flaky test, and how do you handle one?

Sample answer: “A flaky test passes and fails on the same code without any change. Common causes are hard-coded waits, shared test data, test order dependencies and unstable environments. I quarantine it so it doesn’t block the pipeline, find the cause, usually replacing sleeps with proper waits or isolating data, then bring it back.”

27. Which automation tools have you used?

Answer with what you’ve actually used and why. Common names: Selenium (long-standing browser automation), Playwright and Cypress (modern web testing), Appium (mobile), Postman and REST Assured (APIs), JMeter or k6 (performance), and Jira or similar for tracking. See the best tools for QA and software testing if you need a quick map of the landscape.

28. How do you test an API?

Sample answer: “I check that each endpoint returns the right status code, response body and headers for valid input, then test invalid input, missing fields, wrong data types, missing or expired auth tokens and permission boundaries. I also check error messages, response times and what happens when dependencies fail.” For more, read what is API testing and our API testing interview questions.

29. Why do testers need SQL?

Sample answer: “Because the UI doesn’t always show the truth. After placing a test order, I check the database to confirm the right rows were written with the right values. I also use SQL to set up test data and find records for edge cases.” Expect a simple query or two; our SQL interview questions are good practice.

Scenario questions

Scenario questions are where good candidates separate themselves. The trick is the same every time: ask a clarifying question, then group your tests by category instead of firing off a random list.

30. How would you test a login page?

• Functional: valid login, wrong password, unregistered email, empty fields, case sensitivity, leading or trailing spaces, “remember me”, logout.
• Security: password masked, lockout or CAPTCHA after repeated failures, no detail leaked in error messages (“wrong password” vs “invalid credentials”), SQL injection attempts, HTTPS only, session expires.
• Usability: clear error messages, tab order, show-password toggle, works with a password manager.
• Compatibility: major browsers, mobile sizes, slow connections.
• Performance: response time, many users logging in at once.

31. How would you test a pen (or a lift, or a chair)?

This tests creativity and structure, not knowledge of pens. Ask who it’s for and what kind of pen first, then cover functional (does it write, on what paper, how long), durability (drop it, heat, cold), usability (grip, cap fits), safety (non-toxic ink, cap won’t choke a child) and performance (how many pages per refill).

32. You find a critical bug an hour before release. What do you do?

Sample answer: “I reproduce it once to be sure, document it with clear steps and impact, and tell the release owner straight away rather than waiting for a meeting. I’d give them the facts they need to decide: who’s affected, whether there’s a workaround, and whether it’s new in this build. Whether to delay is a business call, but it should be an informed one.”

33. There’s no documentation for a feature. How do you test it?

Sample answer: “I’d talk to the developer and product owner to learn the intended behaviour, look at similar features, check the existing app and any designs, and use exploratory testing to understand it. I’d write down my assumptions and confirm them, and those notes often become the first version of the test cases.”

Behavioural questions for QA roles

QA interviews nearly always include a few behavioural questions. Use the STAR method (situation, task, action, result), and pick stories that show tester instincts.

• “Tell me about the best bug you’ve found.” Pick one with real impact and explain how you found it, not just what it was.
• “Tell me about a time you disagreed with a developer.” Show that you used evidence and kept the relationship intact.
• “Tell me about a time you missed a bug.” Own it, then explain what you changed in your process afterwards.
• “How do you prioritise when there’s too much to test?” Talk about risk: what’s most used, most changed and most expensive if broken.

For more practice, see our guides to behavioral interview questions and HR interview questions and answers.

Questions for experienced QA candidates

If you have a few years of experience, expect deeper versions of the above:

• How did you design or improve a test strategy for a whole product?
• How do you decide what goes into the CI pipeline and what runs nightly?
• How do you measure quality? (Escaped defects, defect leakage, test coverage of critical flows, flaky test rate.)
• How would you test a feature that uses an AI model, where the output isn’t always the same?
• How have you mentored junior testers or improved how developers test?

How to prepare in one week

1. Days 1 and 2: revise fundamentals and bug questions until you can explain each in two or three sentences without notes.
2. Day 3: practise test design. Write test cases for a login page, a search box and a checkout flow.
3. Day 4: tools. Run a few requests in Postman, write five SQL queries, and review one automation project you’ve built.
4. Day 5: scenario questions out loud, using the “clarify, then group” method.
5. Day 6: write three STAR stories: a great bug, a disagreement, a mistake.
6. Day 7: a mock interview with a friend, then rest.

Want more depth on one area? Our manual testing interview questions go deeper on fundamentals, and QA engineer vs SDET helps if you’re deciding which path to interview for.

Make your resume match the QA role first

None of this matters if your resume doesn’t get you the interview. QA job descriptions vary a lot: one wants manual testing and Jira, the next wants Playwright, API testing and CI pipelines. Sending the same resume to both means one of them sees the wrong skills first.

Tailor the summary and skills section to the exact terms each listing uses, and move your most relevant project to the top. Tailr does this from the job listing you’re viewing: it’s a Chrome extension that tailors your resume to that role, writes a matching cover letter and tracks the application, so you can spend your prep time on the interview instead.

Try Tailr

Related guides

• Test Case vs Test Scenario vs Test Plan: Differences With Examples
• Top SDET interview questions and answers

Conclusion

QA interviews reward structured thinking more than memorised definitions. Know the fundamentals well enough to explain them simply, have real examples for severity vs priority and the bug life cycle, and practise scenario questions with the “clarify, then group” method. Add two or three honest stories about bugs you’ve found, and you’ll walk in ready for most QA interviews.