Put this into action
Turn this guide into better conversations with Articuler
Use this guide as the research layer, then turn the next step into a live networking workflow: search by intent, prep for the conversation, and send outreach that is built for replies.
Try the Articuler workflowMost QA interviews follow a predictable arc: a few definitions to confirm you know the vocabulary, then scenario questions that test whether you actually understand *why* those definitions matter. If you can explain the difference between severity and priority with a real example, walk through how you'd test an input field, and show you know when automation pays off, you're ahead of most candidates.
This guide collects the QA interview questions you're most likely to face, grouped by topic, each with a short model answer you can adapt. It covers manual testing, automation, API testing, agile and CI/CD context, and the behavioral questions that decide close calls.
What you'll find here:
- Testing fundamentals: verification vs. validation, QA vs. QC, SDLC vs. STLC
- Manual testing: severity vs. priority, bug life cycle, test design techniques
- Automation, API testing, and how QA fits into agile and CI/CD
- Behavioral questions and how to answer them with real evidence
Testing Fundamentals
These questions confirm you speak the language. Answer them quickly and precisely so the interviewer can move to harder material.
What is the difference between verification and validation?
Verification asks "Are we building the product right?" — checking that work products meet their specifications through reviews, walkthroughs, and inspections. Validation asks "Are we building the right product?" — checking that the finished software actually meets user needs, usually through execution-based testing. As Wikipedia summarizes, verification evaluates whether outputs satisfy the conditions set at the start of a phase, while validation determines whether the system satisfies its specified requirements.
What is the difference between QA, QC, and testing?
These overlap but aren't the same:
- Quality Assurance (QA) is process-focused and preventive — it improves how software is built so defects are less likely.
- Quality Control (QC) is product-focused and corrective — it inspects the actual deliverable to find defects.
- Testing is one QC activity — executing the software to find failures.
A clean one-liner: QA prevents, QC detects, testing is how QC detects.
What is the difference between SDLC and STLC?
The Software Development Life Cycle (SDLC) covers the whole project — requirements, design, build, test, deploy, maintain. The Software Testing Life Cycle (STLC) is the testing portion within it: requirement analysis, test planning, test case design, environment setup, test execution, and test closure. STLC runs in parallel with SDLC rather than after it.
What is the difference between a test case and a test scenario?
A test scenario is a high-level idea of what to test ("verify login works"). A test case is the detailed, step-by-step instruction set with preconditions, inputs, steps, and expected results that proves the scenario. One scenario usually spawns several test cases — valid login, wrong password, locked account, and so on.
Manual Testing Questions
This is where most interviews spend their time. Expect scenario questions, not just definitions.
What is the difference between severity and priority?
This is the most common QA interview question, and interviewers want a concrete example, not just the definitions.
Severity describes the technical impact of a defect — how badly it breaks the system. Priority describes how soon it should be fixed — a business and scheduling decision. The two are set independently, which is why all four combinations exist. The ISTQB glossary defines severity as the degree of impact a defect has on the development or operation of a component or system, and priority as the level of business importance assigned to an item.
| Combination | Example | Why |
|---|---|---|
| High severity, high priority | Checkout crashes for all users | Breaks core flow, costs revenue now |
| High severity, low priority | App crashes on a browser nobody uses | Severe but rarely hit |
| Low severity, high priority | Company logo misspelled on the homepage | Cosmetic but visible and embarrassing |
| Low severity, low priority | Minor text alignment on a buried settings page | Small impact, no urgency |
Walk me through the bug life cycle.
A defect moves through a defined set of states from discovery to closure. The typical path:
- New — tester logs the defect.
- Assigned — a lead assigns it to a developer.
- Open — the developer starts investigating.
- Fixed — the developer resolves it and marks it ready to verify.
- Retest — the tester re-runs the case against the fix.
- Closed — the fix is verified and the defect is done.
Two important branches: a developer can mark a defect Rejected (not a bug) or Deferred (valid but postponed), and a tester can move a fixed defect to Reopened if it fails retest.
What is the difference between regression testing and retesting?
Retesting confirms that a specific defect has actually been fixed — you re-run the exact failed test case against the new build. Regression testing checks that the fix (or any new change) didn't break previously working functionality elsewhere. Per Wikipedia, regression testing focuses on finding defects after a major code change and catching old bugs that have come back; it's often the largest test effort in commercial development. Retesting is narrow and planned; regression is broad and often automated.
What is the difference between smoke testing and sanity testing?
Both are quick checks, but they answer different questions:
| Aspect | Smoke testing | Sanity testing |
|---|---|---|
| Purpose | Is the build stable enough to test at all? | Does a specific fix or feature work as expected? |
| Scope | Wide and shallow — core flows only | Narrow and focused — the changed area |
| When | On every new build before deeper testing | After a minor change or bug fix |
| Documentation | Usually scripted | Often unscripted and exploratory |
A useful framing: smoke testing verifies the build doesn't "catch fire" on the basics; sanity testing verifies a particular change is "sane" before you invest in full regression.
How do you design test cases for an input field that accepts ages 18 to 60?
This question checks whether you know equivalence partitioning and boundary value analysis — and whether you apply them. Don't just name them; show the values.
Equivalence partitioning divides inputs into groups expected to behave the same, so you test one value per group instead of every value. As Wikipedia explains, it divides input data into partitions of equivalent data from which test cases can be derived. Here the partitions are: below 18 (invalid), 18–60 (valid), and above 60 (invalid). Pick one from each — say 10, 35, and 70.
Boundary value analysis then targets the edges, where bugs cluster. As Wikipedia notes, tests are designed to include representatives of boundary values in a range. So you test 17, 18, 19 at the lower edge and 59, 60, 61 at the upper edge. Together these two techniques give strong coverage with a handful of cases instead of dozens.
Automation Testing Questions
Even manual roles increasingly expect automation awareness. These questions separate people who can write a script from people who understand a framework.
What is Selenium and what are its main components?
Selenium is an open-source suite for automating browsers. Selenium WebDriver drives a browser natively, as a user would, and is a W3C standard recommendation supporting Chrome, Edge, Firefox, Safari, and others across multiple language bindings. The suite also includes Selenium IDE (record-and-playback for quick scripts) and Selenium Grid (running tests in parallel across machines and browsers). For role-specific drills, see our Selenium interview questions guide.
What is a test automation framework?
A framework is the structure and set of conventions that make automated tests maintainable — not just a pile of scripts. Common types include data-driven (test logic separated from test data), keyword-driven (actions abstracted into reusable keywords), and the Page Object Model, where each page's locators and actions live in one class so a UI change is fixed in a single place. A good framework adds reporting, logging, configuration, and reusable utilities so the suite scales without becoming brittle.
When should you automate a test, and when shouldn't you?
Automate tests that are repetitive, stable, and high-value — regression suites, smoke checks, data-driven scenarios, and anything run on every build. Keep manual the tests that are exploratory, one-off, or constantly changing — early-stage features, usability and look-and-feel checks, and edge cases you'd spend more time scripting than running. The honest answer interviewers want: automation has an upfront cost, so it pays off when a test runs many times, not once.
API and Agile/CI-CD Questions
Modern QA work lives below the UI and inside the pipeline. Expect questions on both.
What is API testing and why test at the API layer?
API testing validates application programming interfaces directly — checking responses, status codes, data formats, error handling, performance, and security — rather than going through the UI. The advantage: the API is the most stable interface to the system, so these tests are less brittle and easier to maintain than GUI tests, which need constant rework as the interface changes. In practice you verify the right status code (200, 201, 400, 404, 500), the response body matches the schema, and the endpoint handles bad input gracefully. Tools like Postman or REST-assured are common here.
How does QA work in an agile team?
In agile, QA is continuous, not a phase at the end. Testers join sprint planning, help refine acceptance criteria, test stories within the sprint, and pair with developers to catch issues early. The "shift-left" idea is to test as soon as something is buildable rather than waiting for a hardening phase. A strong answer mentions the three amigos (business, dev, QA discussing a story together) and writing acceptance criteria that are testable.
How does testing fit into a CI/CD pipeline?
Continuous integration means integrating code changes frequently and keeping the codebase in a workable state, with automated builds and tests running on every commit. Testing is the gate: unit tests run first, then API and integration tests, then a subset of UI tests — fast checks early so failures surface in minutes. A common practice is that every bug-fix commit ships with a test that prevents the regression from returning. If you can explain where you'd put smoke vs. full regression in a pipeline, you'll stand out.
Behavioral Questions for QA Roles
Technical answers get you to the final round; behavioral answers often decide it. Use the STAR structure — Situation, Task, Action, Result — and bring real numbers.
- "Tell me about a critical bug you found late in a release." Show judgment: how you assessed severity and priority, who you escalated to, and the outcome. Interviewers want to see you balance quality against shipping pressure, not block releases reflexively.
- "How do you handle a developer who disagrees that your bug is valid?" Demonstrate that you argue with evidence — clear reproduction steps, screenshots, logs — and stay collaborative rather than territorial.
- "How do you decide what to test when there's no time to test everything?" Talk about risk-based testing: prioritize by likelihood of failure and business impact, cover the critical paths first, and communicate what you didn't cover.
- "Describe a time you improved a testing process." This is your chance to show initiative — a flaky suite you stabilized, a regression cycle you cut with automation, a defect-tracking habit you introduced.
For broader interview prep beyond QA specifics, our guides on behavioral interview questions and how to ace an interview cover structure and delivery. If you're also interviewing for adjacent engineering roles, the technical interview questions guide is worth a read.
Frequently Asked Questions
Prepare for the Specific Interview, Not a Generic One
Knowing the definitions gets you past the screen. What wins the offer is walking in knowing the team's stack, the interviewer's background, and the kind of quality problems they actually wrestle with. Articuler helps jobseekers find the hiring manager behind a QA posting, build a Playbook on what that specific person cares about, and send a personalized note that earns a reply at roughly 8x the rate of a generic message. You can also use it to prep for the interview itself on the people who'll be in the room.
Next step
Use Articuler to act on what you just read
Start with one concrete goal: investor intros, sales prospects, event meetings, hiring-manager outreach, or expert conversations. Articuler turns that goal into people, prep, and messages.
Start networking with intent