In this article
Before you start
Testing vocabulary varies between companies, so the answers below are working definitions; where a published source applies it is linked, namely Martin Fowler's Test Pyramid and Test Double pages and Ham Vocke's practical article. Say which meaning you are using when you answer. A QA analyst role usually leans toward test analysis, requirements and manual testing, and a QA engineer role toward automation and tooling, though employers use the titles loosely. If your target role also has coding rounds, practice them with the coding interview guide.
Testing basics
What is the difference between QA, QC and testing?
Quality assurance is the work of preventing defects by shaping how software is built: standards, reviews, test strategy and process. Quality control (QC) is checking a built product against its requirements. Testing is one quality control activity: running the software to find defects. Job titles blur the three, so say which meaning you use and give one example of each from your own work.
Why it is asked: it checks that you know the vocabulary and see the role as more than clicking through screens.
What is the difference between verification and validation?
Verification asks whether the product was built to its specification, using reviews, static checks and tests against requirements. Validation asks whether the specification, and so the product, meets what users actually need. A feature can pass verification and fail validation when the requirement was wrong. Example: a report exports exactly as specified, but customers wanted a format their accounting tool can open.
Why it is asked: it shows whether you question requirements or only follow them.
What is the difference between severity and priority?
Severity is how badly a defect damages the product; priority is how soon the team should fix it. They differ: a crash in a rarely used admin screen is high severity and may be low priority, while a misspelled company name on the home page is low severity and may be high priority. Testers often propose severity; the product owner usually decides priority.
Why it is asked: it tests judgment about impact versus urgency, and a common mix-up.
Can testing prove that software has no bugs?
No. Testing can show that defects are present, but it cannot show that none remain, because the number of possible inputs, states and sequences is far too large to try them all. So testers choose tests by risk and by technique, then report what was covered and what was not, rather than claiming the software is bug-free. State the remaining risk plainly.
Why it is asked: it separates realistic testers from people who promise perfection.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Test design
What makes a good test case?
A good test case has a clear purpose, preconditions, exact steps, test data and an expected result that someone else can check without asking you. It tests one thing, so a failure points at one cause, and it gives the same outcome when repeated. Link it to a requirement or risk so its purpose is visible. A vague expected result such as "works correctly" is the weakness to avoid.
Why it is asked: written test cases show how precise and how clear your thinking is.
What are equivalence partitioning and boundary value analysis?
Equivalence partitioning splits inputs into groups the program should treat alike, then tests one value from each group. Boundary value analysis is testing at the edges of those groups, where off-by-one mistakes sit. In an illustrative age field that accepts 18 to 65, test 17, 18, 19, 64, 65 and 66, plus a non-numeric entry and an empty one.1
Why it is asked: these two techniques show whether you can get strong coverage from few tests.
How do you decide what to test when there is no time to test everything?
Rank features by the chance of failure and the cost of failure, then test the high-risk ones first and deepest. Chance rises with new or changed code, complexity and past defects; cost rises with money, safety, data loss and the number of users affected. Say what you are deliberately skipping and tell the stakeholder, so the trade-off is a shared decision, not a surprise.
Why it is asked: real schedules never allow complete testing, so interviewers want to hear how you prioritize.
What is the difference between smoke, sanity and regression testing?
A smoke test is a quick check that a new build works at all: it starts, you can log in and the main path runs. A sanity test is a narrow check that one fix or change behaves. Regression testing is rerunning earlier tests after a change to see whether previously working behavior broke. Teams use these words loosely, so confirm what your team means.
Why it is asked: it checks that you can match the depth of testing to the situation.
What is exploratory testing?
Exploratory testing is learning the product, designing tests and running them at the same time, without fully scripted steps. The tester follows what they observe and records findings. It suits new features, unclear requirements and problems that scripted checks do not anticipate. Keep it structured with a written goal and a time box, and take notes so every bug can be reproduced. It complements automation rather than replacing it.
Why it is asked: it shows whether you can find problems nobody wrote a test for.
Bugs and defects
What goes into a good bug report?
A good bug report lets a developer reproduce the problem without asking questions: a specific title, the environment and build, numbered steps, the expected result, the actual result, and evidence such as a screenshot, log or recording. It states severity and, when known, how often the problem occurs. One report covers one defect. Search for duplicates first, and write facts, not blame.
Why it is asked: the report is the main thing a tester produces, so its quality shows your craft.
What is the bug life cycle?
A defect typically moves through new, assigned, in progress, fixed, ready for retest, verified and closed. Side exits include duplicate, cannot reproduce, rejected as not a defect, deferred, and reopened when a retest fails. State names differ between trackers and companies, so describe the flow your team used and who owned each transition, with the tester owning verification.
Why it is asked: it shows whether you understand how defects move through a team.
What do you do when a developer says it is not a bug?
Go back to the requirement, not to opinion. Reproduce the behavior, check the specification or acceptance criteria, and compare with what a user would expect. If the specification is silent or ambiguous, bring in the product owner to decide, and record the decision. If it is by design, close the report with the reason; if the design surprises users, re-file it as an improvement.
Why it is asked: it tests evidence-based persuasion without a fight.
Test automation
What is the test pyramid?
The test pyramid is a metaphor for grouping automated tests by granularity: many small, fast unit tests at the base, fewer broader tests in the middle, and very few end-to-end tests through the user interface at the top (Vocke on martinfowler.com, February 2018). Mike Cohn's original layers are unit, service and user interface tests, and the article warns against the inverted shape, a test ice-cream cone that is slow and hard to maintain. Fowler (May 2012) gives a short note on the same idea.
Why it is asked: it checks whether you can design a fast, maintainable test suite. Read the full explanation: The Practical Test Pyramid.
Which tests should you automate, and which should you leave manual?
Automate checks that run often, are stable and deterministic, and matter if they fail: regression suites, application programming interface (API) checks, data-driven cases and the smoke path on every change. Fast automated feedback is the payoff, which Vocke (February 2018) describes as knowing in seconds and minutes instead of days and weeks. Keep exploratory and usability testing manual, and anything that changes weekly.
Why it is asked: it tests whether you weigh the payoff of a script against its upkeep, not whether you can code.
What is a flaky test and how do you fix it?
A flaky test is an automated test that sometimes passes and sometimes fails on the same code. Typical causes are fixed sleeps, shared or leftover test data, dependence on test order and unstable external services. Wait for a condition instead of a fixed time, isolate data, replace external services with test doubles (stand-ins for real dependencies), and quarantine the test while you repair it, so a failing build keeps its meaning.
Why it is asked: flaky tests erode trust in a suite, so interviewers want your method. Read the full explanation: Java interview questions for automation testing.
What is the difference between a mock and a stub?
A test double is an object that stands in for a real dependency during a test (Fowler, Test Double, January 2006). Fowler names five kinds: dummy, fake, stub, spy and mock. A stub returns canned answers; a mock is set up with expectations about the calls it should receive, and the test fails if they are not met. Vocke (February 2018) notes that people often use "mock" and "stub" interchangeably.
Why it is asked: it shows whether you can isolate the code under test. Read the full explanation: JUnit interview questions and answers.
Methodology and metrics
How does testing differ in Agile and waterfall projects?
In a waterfall project, testing is a phase after the build, so feedback on defects arrives late. In an Agile team, testers work inside each iteration: they clarify acceptance criteria before coding, test increments as they finish and automate regression checks, so feedback comes within the iteration. The V-model, a waterfall variant, plans each test level against a development stage. Name the approach you worked in and what you did when an iteration ended with untested work.
Why it is asked: it shows whether you can fit testing into the team's way of working.
How do you measure the quality of your testing?
Defect escape rate is the share of all defects found for a release that were found after release, by users or monitoring, instead of by the team before it. In an illustrative release with 45 defects found before release and 5 found after release, the rate is 10%.1 Pair it with other signals, such as pass rate (illustrative: 188 of 200 tests passing is 94%) and time to fix failures, because any single measure can mislead or be gamed.
Why it is asked: it tests whether you can show the value of testing with evidence.
Lead roles
How would you answer QA lead interview questions on strategy and team?
For a release, write a test strategy: scope, risks ranked by likelihood and impact, test levels, environments, entry and exit criteria, and what you will not test. Automate stable, repeated checks and keep exploratory work manual. Report escaped defects, risk coverage and open critical bugs to management, not raw test counts. Mentor through paired testing and bug-report reviews. For go/no-go, present open risks and let the decision-maker choose.
Why it is asked: a lead role needs judgment about priorities, reporting and people, not only test skills.
Behavioral questions
Tell me about a bug that reached production.
Structure the story as situation, task, action and result (STAR). Pick a real, bounded case: what shipped, how it was found, the impact and how you helped contain it. Then spend most of your time on what changed afterward: a new test, a checklist item, a monitoring alert or a conversation about how it escaped. Own your part without blaming a person, and end on the lesson.
Why it is asked: it shows honesty, ownership and whether you learn from misses.
Tell me about a disagreement with a developer.
Describe one disagreement over a defect or a release decision. Say what you wanted, what the developer wanted and what evidence you brought: a reproduction, a log or the user impact. Show that you listened, found the shared goal and agreed who made the final call when you could not agree. Close with the outcome and the state of the working relationship, and do not cast the developer as the villain.
Why it is asked: testers work between people, and this shows how you handle friction.
Follow-up questions
What are the common QA interview questions?
The most frequent are the difference between QA, QC and testing, severity against priority, what makes a good bug report, which tests to automate, and a story about a bug that reached production. The twenty-one entries above cover those and the wider themes: testing basics, test design, bug handling, automation, methodology, lead roles and behavioral stories. Some automation roles add a coding round, so rehearse that with the coding interview guide.
What are QA interview questions for freshers?
Prepare the basics: QA against QC, severity against priority, writing a test case, writing a bug report, and smoke against regression testing. A good practice exercise is to test a login form aloud: valid and invalid entries, empty fields, length limits and a locked account.
What technical questions are asked in a QA interview?
Prepare for test design techniques, automation design, reading and writing queries to check data, and basic programming in the language your target team uses. For language practice see JavaScript interview questions or Java interview questions, and for roles that span both sides see full stack developer interview questions.
Are there behavioral QA interview questions?
Yes: the last two entries show typical shapes, a bug that escaped and a disagreement with a developer. Prepare two or three real stories in STAR form, each with a clear lesson, and reuse them across questions.
What are Java QA interview questions?
Java automation roles combine test design with Java basics and a test framework. Start with Java interview questions for automation testing, then the JUnit page.
What are QA interview questions for a call center or a technician role?
Call-center QA is a different job: reviewing recorded calls against a scoring form. Expect questions on how you would score a call, agree scores with other reviewers and give feedback. A manufacturing QA technician role is different again: expect questions on inspection, measurement, documentation and following procedures. This page covers software QA, though the habit of clear criteria and evidence carries over.
- Define QA, QC and testing separately, and say testing shows defects, not their absence.
- Design tests with techniques such as boundary values, and choose by risk.
- A good bug report reproduces the problem without further questions.
- Automate stable, repeated checks in a pyramid shape and fix flaky tests.
- Prepare two or three STAR stories, including one bug that got away.
Sources
- The Practical Test Pyramid (Ham Vocke), martinfowler.com — martinfowler.com (Thoughtworks), 26 Feb 2018
- Test Double (Martin Fowler), martinfowler.com — martinfowler.com (Thoughtworks), 17 Jan 2006
- Test Pyramid (Martin Fowler), martinfowler.com — martinfowler.com (Thoughtworks), 1 May 2012
