These QA interview questions help you evaluate the person who will own the quality of your software. A QA engineer keeps defects away from users and protects the customer experience. Beyond culture-fit questions, technical questions show what a candidate can actually do, beyond certifications and years of experience.
What a QA engineer does
QA stands for quality assurance. Developers test their own code, but a QA engineer looks at the whole product: checks that standards and methods are followed, spots deviations, and prevents defects before release.
Common tools include Selenium, Appium, and Cypress for test automation, and Jira, Bugzilla, or MantisBT for bug tracking. In the interview, notice whether the candidate brings these up and whether they already use AI in their testing work.
Validate skills with a technical assessment before the interview
With Coodesh, you run QA and test automation assessments with automatic scoring, so you walk into the interview knowing what to probe. Try technical assessments free.
Junior QA interview questions
1. What is QA?
The process of ensuring software quality and preventing defects before they reach end users, through methods, testing, and best practices that cover functional and non-functional requirements.
What to look for: whether they tie QA to prevention, not just to finding bugs at the end.
2. Why does QA matter in the development lifecycle?
It finds and prevents errors early, which cuts cost and rework and helps the team ship more stable products.
What to look for: cost examples: a bug caught in requirements costs far less than one found in production.
3. What is a software bug?
An error, failure, or unexpected behavior that keeps the system from working as intended. Causes include faulty code, unclear requirements, or integration issues.
What to look for: whether they separate a bug from an unclear requirement or expected behavior the user misunderstands.
4. What is the difference between manual and automated testing?
Manual testing is done by a person without scripts and suits exploratory and visual checks. Automated testing uses scripts and tools for repetitive tasks, with more speed and coverage, especially for regression.
What to look for: that they see the two as complementary, depending on context, not one as better.
5. What is the difference between severity and priority?
Severity is the technical impact of a bug. Priority is how urgently it needs fixing, based on user and business impact. A bug can be highly severe and still low priority, depending on context.
What to look for: a real example of a severe, low-priority bug, like an error on a screen almost no one uses.
6. What is a test case, and what should it include?
A set of conditions and steps to validate a feature. It includes an ID, description, preconditions, steps, input data, expected result, and actual result.
What to look for: expected result and input data. Without them, the test case cannot be repeated.
7. What is the difference between a test strategy and a test plan?
A strategy is high level: approach, test types, and acceptance criteria. A plan is project-specific: scope, schedule, resources, owners, and test cases.
What to look for: that they understand the strategy changes little across projects while the plan changes for each one.
8. What goes into a test plan?
Approach, scope, objectives, resources, schedule, test types, environments, entry and exit criteria, and team responsibilities.
What to look for: clear entry and exit criteria. They show the candidate knows when to start and when to stop.
9. What is the defect lifecycle?
The stages a bug goes through from discovery to closure: new, triaged, in progress, fixed, in retest, and closed.
What to look for: familiarity with the statuses in the tool your team uses, such as Jira.
10. When should quality assurance start?
From day one, ideally during planning and requirements analysis, when fixing problems is cheapest.
What to look for: the shift-left idea: quality from the start, not as a final stage.
11. How do quality assurance, quality control, and testing differ?
QA is proactive and improves processes to prevent defects. QC is reactive and finds defects in the product. Testing is part of QC: running test cases to confirm the software meets requirements.
What to look for: a real example from their own work that shows the difference.
12. What are the basic types of software testing?
Functional (integration, system), non-functional (performance, security, usability), regression, and acceptance testing such as UAT.
What to look for: whether they bring up non-functional testing without being asked.
13. What is the difference between Assert and Verify?
Assert checks a critical condition and stops the test if it fails. Verify logs the failure and lets the test continue, so you can catch several issues in one run.
What to look for: real experience with automation frameworks, not just the definition.
14. Which metrics matter most for product quality?
Defect rate, test coverage, response time, failure rate, and user satisfaction.
What to look for: whether they connect metrics to decisions instead of just listing them.
15. How do you define a use case?
A description of how a user interacts with the system to reach a goal, including the flow of actions, success conditions, and exceptions.
What to look for: the ability to turn a use case into test cases.
16. What are black-box and white-box testing?
Black-box testing validates behavior through inputs and outputs without looking at the code. White-box testing examines the code and internal structure to check paths and conditions.
What to look for: whether they know when they use each approach day to day.
Mid-level QA interview questions
17. What is regression testing, and how is it done?
It confirms that code changes did not break existing features, by rerunning earlier test cases, usually automated.
What to look for: automating regression and choosing which cases to include.
18. Explain test automation.
Using tools and scripts to run tests without manual work, for faster runs, fewer human errors, and more coverage on repetitive tests.
What to look for: what is not worth automating, as well as what is.
19. Which automation tools have you used?
Common answers: Selenium for web UI, JUnit and TestNG for Java unit tests, Appium for mobile, Jenkins for CI, and Cucumber for tests written in plain language. The right tool depends on the application.
What to look for: depth in at least one tool, with examples from real projects.
20. How do you document and report defects?
In a tool like Jira or Bugzilla, with a description, steps to reproduce, severity, priority, environment, and screenshots or logs, then follow up until the fix is verified.
What to look for: reports a developer can reproduce without asking follow-up questions.
21. What is the difference between functional and non-functional testing?
Functional testing checks what the system does, such as login or calculations. Non-functional testing checks how well it does it: performance, security, usability, and reliability.
What to look for: examples of non-functional tests they have actually run, such as load or accessibility.
22. How do you prioritize test cases on a tight deadline?
By risk and impact: critical flows like integrations and security first, then regression, with automation to speed up repetitive checks.
What to look for: risk-based prioritization and honesty with the team about what was skipped.
23. How do you apply Six Sigma in QA?
With the DMAIC cycle (define, measure, analyze, improve, control) to reduce defects and improve the testing process over time.
What to look for: practical application, even a simple one. Six Sigma is not required on every team.
24. How do you decide between manual and automated testing?
Manual for complex interactions and one-off cases. Automated for regression, repetitive checks, and high coverage. It depends on frequency and complexity.
What to look for: cost-benefit reasoning: how often it runs, how stable the feature is, and maintenance time.
25. How do you evaluate a quality management system?
With indicators such as defect rate, customer satisfaction, standards compliance, and operational efficiency, plus continuous feedback.
What to look for: whether they go beyond defects and include customer satisfaction.
26. What is the difference between QA and software testing?
QA is the broad prevention process. Testing is one activity inside QA, focused on detecting defects.
What to look for: that they do not treat the terms as synonyms.
27. What is testware?
All artifacts created for testing: test cases, scripts, data, plans, and tools.
What to look for: where they store these artifacts and how they version them.
28. What is data-driven testing?
Running the same test with different data sets to cover more scenarios and catch failures that limited data would miss.
What to look for: an example with boundary, invalid, or generated data.
29. What are the stages of the bug cycle?
Identify and document, classify, assign to a developer, retest the fix, and close.
What to look for: familiarity with your team workflow and tooling.
30. What is agile testing, and why does it matter?
Testing in short cycles with constant collaboration between developers and QA. It supports continuous delivery, fast feedback, and change during development.
What to look for: experience testing inside the sprint, not at the end of it.
31. What mistakes do QA engineers commonly make?
Letting test cases go stale, skipping non-functional tests, not prioritizing critical paths, reporting defects poorly, and thin regression coverage.
What to look for: self-awareness: mistakes the candidate made and corrected.
32. What is the biggest challenge in QA today?
Keeping coverage and efficiency in agile teams where code changes constantly, while balancing quality, deadlines, and automation.
What to look for: a current view of the field, including AI and flaky tests.
Senior QA interview questions
33. How would you build a test automation framework from scratch?
Pick the tools, structure the project, automate critical flows first, and integrate with CI, with a plan for maintenance and monitoring.
What to look for: justified architecture choices: language, design pattern, and reporting.
34. What are load testing and stress testing?
Load testing checks performance at expected volume. Stress testing pushes the system past capacity to find its breaking point.
What to look for: specific tools, such as JMeter or k6, and how they read the results.
35. How do you ensure coverage in highly complex applications?
Prioritize risky scenarios, combine manual and automated, black-box and white-box testing, run regression, and review documentation often.
What to look for: risk-based prioritization rather than trying to cover everything.
36. Have you worked with CI/CD as a QA engineer?
A strong answer describes pipelines, for example in Jenkins, that run tests on every commit and block deployment when they fail.
What to look for: real pipelines, and what happens when a test fails in one.
37. How do you use test metrics to improve the QA process?
Code coverage, defect rate, and execution time help prioritize critical tests and tune the process.
What to look for: whether they use metrics to change something, not just to report.
38. How do you ensure quality during product design?
Analyze requirements, involve QA early, review designs, run usability tests, and apply standards.
What to look for: involvement in requirements reviews and prototypes.
39. How do you bring user feedback into QA?
Collect it in betas or interviews, look for recurring issues, and adjust test cases and priorities.
What to look for: an example of changing tests based on what users said.
40. Why is FMEA important?
Failure mode and effects analysis identifies potential failures and ranks them by severity, likelihood, and detectability before they cause harm.
What to look for: whether they can explain severity, likelihood, and detectability.
41. How do you prioritize during a quality crisis?
Fix the critical, high-frequency defects that hurt users most, communicate constantly, and adjust the process so they do not recur.
What to look for: composure, prioritization, and communication with leadership.
42. What are the advantages of manual testing?
It catches usability and experience issues, adapts to frequent changes, and works for exploratory testing or when automation is not worth it.
What to look for: a case for manual testing that does not dismiss automation.
43. What is the difference between a build number and a version number?
A build number is generated automatically on every build. A version number is assigned to identify stable releases.
What to look for: familiarity with your version control and release practices.
44. What is bug leakage versus bug release?
Leakage means defects slipped through testing into production. A bug release means the team chose to ship with known defects.
What to look for: ownership of leaks and lessons learned after shipping with known bugs.
45. How do you run a root cause analysis?
Gather data, use techniques like the 5 Whys or an Ishikawa diagram, apply corrective and preventive actions, and test that the issue does not return.
What to look for: a complete example, from the problem to the preventive action.
46. What do you do when quality standards are not met?
Analyze the cause, fix the tests or the process, and track results in the next releases.
What to look for: process changes, not just one-off fixes.
47. How do you mentor junior QA engineers?
With solid fundamentals, guided practice, frequent feedback, mentoring, and ongoing training.
What to look for: real experience coaching people and measuring their progress.
48. When is regression testing appropriate?
After new features, bug fixes, dependency updates, refactors, or changes in connected systems.
What to look for: specific situations instead of a generic answer.
49. Describe a test strategy that worked for you.
A good answer combines unit, integration, and system tests, manual and automated, with regression and a focus on critical areas.
What to look for: a strategy tied to a concrete product and context.
50. Which testing tools do you use day to day?
For example, Selenium for UI, Jira for defects, TestRail for test cases, Postman for APIs, and Jenkins for CI.
What to look for: tools that match your stack, or the ability to learn them fast.
How to use these QA interview questions in your hiring process
- Match questions to the level. Focus on concepts for junior roles and on strategy, leadership, and trade-offs for senior roles.
- Listen for depth. Check that answers match the experience on the resume, and ask how they would handle real day-to-day problems.
- Ask for real examples. Past projects reveal strengths to use from day one and gaps to work on in their development plan.
The answers to these QA interview questions are a reference. Strong candidates go further and explain the reasoning behind their choices.
10 behavioral QA interview questions
Technical questions show what a candidate knows. Behavioral questions show how they act when quality collides with deadlines, priorities, or people. For each one, here is what to listen for.
- Tell me about a critical bug you found right before a release. What did you do? Listen for clear risk communication, data behind the call, and respect for whoever decides whether to ship.
- Has a developer ever disagreed with a bug you reported? How did you resolve it? Listen for collaboration and evidence, not a contest over who is right.
- Describe a time you had to test something with no documentation. Listen for exploratory testing, asking the right people, and writing down what they learned.
- How did you decide what not to test in a short sprint? Listen for risk-based prioritization and transparency about what was left out.
- Tell me about a bug you missed that reached production. Listen for ownership, root cause analysis, and a concrete process change. Be wary of anyone who says it never happened.
- How did you convince your team to invest in automation? Listen for cost and risk arguments, not just technical preference.
- What did you do when your automated tests started failing intermittently? Listen for diagnosing flaky tests, isolating dependencies, and the discipline not to ignore failures.
- How do you work with product to define acceptance criteria? Listen for early involvement and testable criteria.
- How do you use AI in your testing work? Listen for critical use: generating test cases or data and reviewing them, not accepting tool output unchecked.
- What quality improvement did you lead, and how did you measure it? Listen for before-and-after metrics, such as production defects or regression time.
Green flags and red flags in QA answers
Green flags:
- Talks about risk to users and the business, not just bug counts.
- Gives concrete examples with tools, context, and outcomes.
- Acknowledges limits: knows you cannot test everything and explains how they choose.
- Shows good working relationships with engineering and product.
- Knows API and performance testing, not just UI testing.
Red flags:
- Describes the job as “catching developers’ mistakes.”
- Answers everything with theory and no examples of their own.
- Cannot explain how they prioritize when time runs out.
- Claims to automate everything, with no judgment on what is worth automating.
- Never mentions documenting or communicating defects.
Hands-on exercises to assess QA candidates
An interview shows how someone talks about quality. A hands-on exercise shows how they do it. These three exercises cover the most common levels:
Exercise 1: test cases for a login form (junior)
Share a login screen with simple requirements (email, password, lockout after five attempts, password reset) and ask the candidate to write the test cases. Score coverage of positive and negative cases, boundaries, error messages, basic security, and clarity of steps.
Exercise 2: bug reports on a buggy app (mid-level)
Give access to a test app with planted defects and 45 minutes to explore. Score how many relevant bugs they find, how they prioritize them, and the quality of each report: steps to reproduce, expected result, actual result, severity, and evidence.
Exercise 3: automating a critical flow (senior)
Ask them to automate a flow, such as adding a product to the cart and checking out, with your team’s tool (Playwright, Cypress, or Selenium), plus an API test for the same flow. Score project structure, test stability, good practices like page objects, and their explanation of what they would leave out of automation and why.
Manual QA vs. automation QA: what changes in the interview
- Manual QA: weight exploratory testing, test design, defect communication, and business knowledge. QA interview questions 3, 4, 6, 12, and 15 are the most useful.
- Automation QA: weight programming, framework architecture, CI/CD, and test stability. Questions 18, 19, 33, 36, and the behavioral question on flaky tests help separate candidates.
- Performance or security QA: add specific questions on tools like JMeter or k6 and on common vulnerability testing.
QA interview scorecard
| Dimension | What you assess | Suggested weight |
|---|---|---|
| Quality fundamentals | Concepts, test types, defect lifecycle | 25% |
| Hands-on skill | Result of the practical exercise | 35% |
| Prioritization and risk | How they decide what to test and when to ship | 20% |
| Communication and collaboration | Working with engineering and product | 20% |
Adjust the weights to the role. For automation QA, hands-on skill can weigh more; for a QA lead, prioritization and communication.
How to run a 60-minute QA interview
- Opening (5 minutes): introduce the team, the product, and the interview format. It lowers tension and improves answers.
- Experience (10 minutes): ask about their last project and how quality was organized on that team.
- Technical questions (20 minutes): pick 8 to 10 QA interview questions from this list by level, and dig into shallow answers.
- Behavioral questions (15 minutes): use three or four from the list and ask for concrete examples.
- Candidate questions (10 minutes): what they ask is evidence too. Strong QA engineers usually ask about the release process, current coverage, and how QA works with engineering.
Record your score right after the interview, using the scorecard, before you talk to other panelists. That keeps one opinion from shaping the rest.
QA interview questions FAQ
How many QA interview questions should I use in one interview?
Ten to fifteen technical questions and three or four behavioral ones in a one-hour interview. Choose by level and QA type.
Do I need a hands-on exercise?
Yes, especially for automation roles. Many candidates explain concepts well and struggle to apply them.
Which certifications are worth it?
ISTQB is the best known and shows a theoretical foundation. It does not replace hands-on experience or a good technical assessment.
Who should be on the interview panel?
A recruiter for the first screen, a QA engineer or engineering lead for the technical part, and ideally someone from product or engineering who will work with the hire.
Related reading
- Online Coding Tests: A Strategic Way to Assess Developers
- React Interview Questions: 50 Questions to Assess Front-End Developers
- Cognitive Ability Tests: How to Use Them to Hire Better and Faster
Conclusion
With a clear guide, interviewing a QA engineer gets much easier for recruiters and engineering leads. These 50 QA interview questions cover junior, mid-level, and senior candidates. To walk into the interview with evidence, pair the conversation with a technical assessment.
Assess QA candidates before the interview
Coodesh validates tech professionals, including manual and automation QA engineers, with hands-on tests, automatic scoring, and anti-cheating controls.
Try Coodesh technical assessments free
Large company or custom needs? Book a demo with our team.
