Interview guide · Technology roles
QA tester interview questions
In short
Strong QA tester interview questions test how a candidate designs test cases from requirements, finds edge cases others miss, writes bug reports developers can act on, decides what to test when time is short, and where automation fits. Below are 33 questions for manual testers, QA analysts and QA engineers, with what good answers include, red flags, sample answers and a scorecard.
A good QA tester is part skeptic, part detective and part diplomat. They read a requirement and immediately ask what happens with an empty field, a 300-character name, a slow connection or a user who clicks Submit twice. They write a bug report that a developer can reproduce on the first try. And they tell a product manager, calmly and with evidence, that a release isn't ready. The role ranges from manual testing of web and mobile apps, through API and data testing, to QA engineers who build automated suites in Selenium, Playwright or Cypress.
Use these questions for manual QA testers, QA analysts, software testers in outsourced testing centers and QA engineers with automation duties. For entry-level and manual roles, focus on the opening, testing fundamentals and practical exercises. For QA engineers, add the automation group. Ask the same core questions of every candidate for the role, give one hands-on exercise (testing a simple form or a login page is plenty), and score against the scorecard straight after the interview.
What to look for in a qa tester
- Curiosity about how things breakThe best testers instinctively try boundaries, odd inputs and unusual sequences. That instinct finds the defects scripted happy-path tests never reach.
- Clear, reproducible bug reportsA defect nobody can reproduce wastes developer time and often gets closed. Steps, expected versus actual, environment and evidence are the tester's main output.
- Risk-based prioritizationThere's never time to test everything. Testers who focus on high-risk, high-use paths first protect releases far better than those who work through a list in order.
- Attention to detail with a sense of proportionNoticing a misaligned button matters; calling it a blocker doesn't. Good testers set severity honestly.
- Constructive communication with developersTesting works when developers trust QA. Testers who report facts without blame and help reproduce issues get bugs fixed faster.
- Automation judgmentFor QA engineers, knowing what to automate (stable, repeated, high-value checks) and what not to is worth more than knowing a framework's syntax.
Opening questions
Tell me about the product you test now and what your testing covers.
- Why ask it
- Sets context and depth.
- A strong answer
- Describes the product type (web, mobile, API, data), team size, release cadence, the kinds of testing they do (functional, regression, exploratory, API, performance) and tools used.
- Red flags
- Vague about what they actually tested.
What do you enjoy about testing, and what frustrates you?
- Why ask it
- Motivation and realism.
- A strong answer
- Enjoys finding issues and improving quality; mentions realistic frustrations such as late requirements, handled constructively.
- Red flags
- Sees QA only as a path out of QA, or blames developers for everything.
What's the most interesting bug you've found?
- Why ask it
- Reveals curiosity and method.
- A strong answer
- A specific bug, how they noticed it, how they isolated the conditions and what impact it would have had in production.
- Red flags
- Only cosmetic issues or can't recall one.
How have you learned testing: courses, certifications, on the job?
- Why ask it
- Learning path and foundations.
- A strong answer
- Any mix is fine; looks for genuine engagement, such as ISTQB study, testing communities, or self-taught automation with examples.
- Red flags
- No interest in improving their craft.
Testing fundamentals
How would you test a login page?
- Why ask it
- The classic practical question, still very revealing.
- A strong answer
- Covers valid and invalid credentials, empty fields, case sensitivity, password masking, lockout after failed attempts, error messages that don't reveal which field is wrong, password reset, remember me, session timeout, SQL injection and script inputs, accessibility, browsers and mobile, and performance under load.
- Red flags
- Lists only correct and incorrect password.
What's the difference between verification and validation?
- Why ask it
- Basic concept for QA analysts.
- A strong answer
- Verification checks the product is built to spec (reviews, inspections, testing against requirements); validation checks it meets the user's real need.
- Red flags
- Treats them as the same.
Explain severity versus priority with an example.
- Why ask it
- Common confusion that causes conflict.
- A strong answer
- Severity is impact on the system; priority is urgency to fix. A typo in the company name on the home page is low severity, high priority; a crash in a rarely used admin report may be high severity, lower priority.
- Red flags
- Can't separate the two.
What makes a good test case?
- Why ask it
- Core skill for manual testers.
- A strong answer
- Clear title and objective, preconditions, specific steps, test data, expected result, traceability to a requirement, and independence from other tests. Not so detailed it can't be maintained.
- Red flags
- Steps like 'test the page' with no expected result.
How do you use boundary value analysis and equivalence partitioning?
- Why ask it
- Test design techniques.
- A strong answer
- For an age field accepting 18 to 65, tests 17, 18, 65, 66 and a representative from each valid and invalid class, plus non-numeric and empty input.
- Red flags
- Doesn't know the techniques or applies them without example.
What's the difference between smoke, sanity and regression testing?
- Why ask it
- Terminology used daily in release work.
- A strong answer
- Smoke checks a build's core functions work enough to test further; sanity checks a specific fix or area after a change; regression checks existing features still work after changes.
- Red flags
- Uses the terms interchangeably.
What do you include in a bug report?
- Why ask it
- Main output of a tester.
- A strong answer
- Clear title, environment and build, exact steps, test data, expected versus actual result, severity, screenshots, video or logs, frequency, and any workaround.
- Red flags
- Title-only reports or 'it doesn't work'.
How do you test when there are no written requirements?
- Why ask it
- Common real-world situation.
- A strong answer
- Talks to product owners and developers, uses similar features, user expectations and standards as oracles, documents assumptions, and does structured exploratory testing.
- Red flags
- Refuses to test without a spec.
What is exploratory testing, and how do you keep it structured?
- Why ask it
- Separates thoughtful testers from script followers.
- A strong answer
- Simultaneous learning, design and execution; uses charters, time boxes, notes and debriefs, and turns findings into test cases or automation where useful.
- Red flags
- Describes it as random clicking.
API, data and automation questions
How would you test a REST API endpoint that creates a customer?
- Why ask it
- API testing is now standard for QA.
- A strong answer
- Valid and invalid payloads, required fields, data types and lengths, duplicates, status codes, response schema, authentication and authorization, idempotency, and checks that the record is stored correctly. Names tools such as Postman or a code-based client.
- Red flags
- Only checks for a 200 response.
How do you decide what to automate?
- Why ask it
- Automation judgment.
- A strong answer
- Stable, repetitive, high-value and data-driven tests, especially regression and smoke suites and API checks. Leaves volatile UI, one-off and exploratory testing manual. Considers maintenance cost.
- Red flags
- Automate everything, or nothing.
Which automation framework have you used, and how was your suite structured?
- Why ask it
- Hands-on experience for QA engineers.
- A strong answer
- Names the framework (Selenium, Playwright, Cypress, Appium, REST-assured), page object or similar pattern, test data management, CI integration and reporting.
- Red flags
- Has only recorded scripts with a record-and-playback tool and never maintained them.
Your automated tests are flaky. How do you fix that?
- Why ask it
- Real maintenance problem.
- A strong answer
- Finds root causes: hard-coded waits instead of explicit waits, shared test data, test order dependence, unstable environments, brittle selectors. Quarantines and fixes rather than rerunning until green.
- Red flags
- Adds sleep statements everywhere.
How do you check data in the database during testing?
- Why ask it
- Back-end validation skill.
- A strong answer
- Writes basic SQL to confirm records created, updated or deleted correctly, checks constraints and related tables, and uses safe read-only access.
- Red flags
- Can't write a simple SELECT with a WHERE clause.
Where does performance testing fit, and have you done any?
- Why ask it
- Awareness of non-functional testing.
- A strong answer
- Explains load, stress and soak testing, tools like JMeter, Gatling or k6, response time and error rate goals, and when to involve specialists.
- Red flags
- Unaware that performance is part of quality.
Behavioral questions
Tell me about a time a developer disagreed that something was a bug.
- Why ask it
- Collaboration under friction.
- A strong answer
- Went back to the requirement or user impact, provided evidence, involved the product owner if needed, and kept the relationship good.
- Red flags
- Escalated immediately or gave up without discussion.
Describe a bug that escaped to production. What did you learn?
- Why ask it
- Ownership and improvement.
- A strong answer
- Honest account, why it was missed (test gap, environment difference, time pressure) and what they changed, such as a new regression test or checklist.
- Red flags
- Blames developers entirely.
Tell me about a time you had very little time to test before a release.
- Why ask it
- Prioritization under pressure.
- A strong answer
- Prioritized by risk and usage, communicated what was and wasn't tested, documented residual risk, and followed up after release.
- Red flags
- Signed off without saying what was untested.
Describe a process improvement you introduced in a QA team.
- Why ask it
- Initiative.
- A strong answer
- Specific improvement, such as a bug template, test data setup, a shift-left review of requirements, or an automated smoke suite, with measurable result.
- Red flags
- No examples of improving anything.
Tell me about a time you found a problem in requirements before development started.
- Why ask it
- Shift-left value.
- A strong answer
- Spotted ambiguity or a missing case in a story, raised it in refinement, and saved rework.
- Red flags
- Only tests after code is finished.
Situational questions
It's release day and you find a medium-severity bug. The product manager wants to ship. What do you do?
- Why ask it
- Judgment and communication.
- A strong answer
- Describes the bug's impact clearly, suggests options (ship with a known issue and workaround, feature flag, quick fix), lets the decision owner decide with full information, and documents it.
- Red flags
- Hides the bug or blocks release with no discussion.
You're given a new feature with no test environment access until two days before release. How do you prepare?
- Why ask it
- Planning under constraints.
- A strong answer
- Reviews requirements and designs, writes test cases and data in advance, tests APIs or components earlier if possible, and flags the risk to the team.
- Red flags
- Waits until access arrives.
A bug you reported is closed as 'cannot reproduce.' What next?
- Why ask it
- Persistence and precision.
- A strong answer
- Rechecks environment, data, build and steps, records a video or logs, pairs with the developer to reproduce, and reopens with new evidence.
- Red flags
- Lets it go or reopens with the same report.
You're testing a feature used by contact center agents during live calls. What would you pay extra attention to?
- Why ask it
- User context awareness.
- A strong answer
- Speed and number of clicks, keyboard shortcuts, behavior under slow networks, concurrent users, error recovery mid-task, and accessibility for long shifts.
- Red flags
- Tests only functional correctness.
Questions for senior QA and QA lead candidates
How would you build a test strategy for a new product?
- Why ask it
- Strategic thinking.
- A strong answer
- Covers scope, risks, test levels (unit, integration, end-to-end), the testing pyramid, environments, data, automation approach, non-functional testing, entry and exit criteria, and metrics.
- Red flags
- Only manual end-to-end testing.
What QA metrics do you track, and which do you distrust?
- Why ask it
- Measurement maturity.
- A strong answer
- Escaped defects, defect detection by stage, test coverage of critical paths, automation stability and cycle time; distrusts raw bug counts and test case counts as targets.
- Red flags
- Measures testers by number of bugs logged.
How do you onboard and coach new testers?
- Why ask it
- Leadership.
- A strong answer
- Product walkthroughs, paired testing, reviewing their bug reports, gradually increasing ownership, and a written guide to standards.
- Red flags
- Leaves new testers to figure it out.
Sample answers
I'd start with the obvious: valid username and password logs in, invalid ones don't, and the error message doesn't say which one was wrong. Then boundaries and odd inputs: empty fields, very long strings, spaces before or after, special characters and inputs like a SQL injection string or a script tag. I'd check lockout after the set number of failures, the password reset flow end to end, and that the password field is masked and not autocompleted where it shouldn't be. I'd test session behavior: remember me, timeout, logging in on two devices, and the back button after logout. Finally, keyboard-only use and screen reader labels, a few browsers and mobile, and how long login takes under load.
I logged that a discount code could be applied twice if you clicked Apply quickly. The developer said users wouldn't do that and marked it as won't fix. Instead of arguing, I recorded a short video showing it took two fast clicks, and checked the analytics with our product owner. We had customers on slow mobile connections who double-tapped buttons all the time. Once the product owner saw the potential revenue loss, it was prioritized. The developer and I talked afterwards and agreed I'd include business impact in reports like that from the start, which made our later conversations much easier.
It's not my call alone, but it's my job to make sure the decision is informed. I'd write up the bug clearly: what triggers it, who it affects, how often we'd expect it, and whether there's a workaround. Then I'd talk to the product manager and the developer together and put options on the table: ship with a known-issue note and the support team briefed, hide the feature behind a flag, or hold an hour for a fix if it's small. Whatever we decide, I record it in the release notes or ticket, and I add a regression test so we catch it if it comes back.
Interview scorecard
| Competency | Weight | Strong (4–5) | Weak (1–2) |
|---|---|---|---|
| Test design and coverage | 25% | Finds boundaries, negative cases and non-functional risks; uses design techniques naturally. | Tests only the happy path. |
| Bug reporting and documentation | 20% | Reproducible reports with steps, environment, evidence and honest severity; maintainable test cases. | Vague reports, inflated severity, unclear test cases. |
| Risk-based prioritization | 15% | Focuses on high-risk and high-use areas first and communicates what wasn't tested. | Works through lists in order, signs off silently. |
| Technical testing skills (API, SQL, automation) | 20% | Tests APIs and data directly; for QA engineers, builds stable, maintainable automation integrated in CI. | UI-only testing, no SQL, flaky or unmaintained scripts. |
| Collaboration and communication | 10% | Fact-based, blame-free communication with developers and product owners. | Adversarial or passive. |
| Curiosity and improvement | 10% | Explores, asks why, improves QA process. | Follows scripts only, no initiative. |
Score each competency from 1 to 5 straight after the interview, before discussing the candidate with anyone else, then multiply by the weight.
How to structure a QA tester interview
For most QA roles, a three-step process works:
- Recruiter screen (15 to 20 minutes). Confirm the type of testing done (manual, API, automation), tools, domain, schedule and pay range. One quick question such as 'how would you test a pencil?' shows whether the candidate thinks in test cases at all.
- Practical exercise (30 to 45 minutes). Give a simple web form or a short requirement and ask the candidate to write test cases and log two bug reports from a seeded defect. This single exercise predicts more than the rest of the interview combined. For volume hiring, an online skills assessment with a seeded bug-finding task can run before any interviews.
- Technical and team interview (45 to 60 minutes) with a QA lead and a developer: fundamentals, two behavioral questions, one situational release-day question, and for QA engineers, a code review of a short automated test.
For QA engineers who write production-grade automation, borrow a coding question from the software engineer interview questions. For QA analyst roles that sit close to requirements and user acceptance testing, questions from the business analyst interview questions help too.
Mistakes interviewers make
Only asking definitions. Candidates can memorize the difference between smoke and sanity testing. Few can fake a good set of test cases for a real form in 20 minutes.
Ignoring the bug report. It's the main thing a tester produces, yet many interviews never ask to see one. Always include a bug-writing task.
Hiring automation skills without testing skills. An engineer who can write Selenium code but doesn't know what to test builds large suites that miss real defects.
Undervaluing manual testers. Exploratory testing finds different bugs from automation. In product areas that change weekly, a strong manual tester is often more valuable than another automated suite.
Not checking detail orientation directly. Our attention to detail interview questions include short exercises that work well alongside a practical testing task.
Hiring testers in volume for testing centers
Outsourced testing providers, BPOs running app testing or content QA, and large companies staffing a release program may hire 10 to 50 testers at a time, often entry level. At that scale, consistency comes from a standard practical exercise with a scoring rubric (number and quality of test cases, accuracy of bug reports, severity judgment), a short structured interview with the same questions for every candidate, and calibration sessions where interviewers score the same exercise together.
Screen early with an online test that includes a seeded defect and a short written bug report, then interview only those above the cut score. Track which candidates go on to produce accurate bug reports and low escape rates in their first 90 days, and use that to adjust the cut score and the questions you keep.
Frequently asked questions
What are common QA interview questions?
Expect to test a login page or simple form, explain severity versus priority, describe a good bug report, compare smoke, sanity and regression testing, explain how you decide what to automate, and describe a bug that escaped to production.
What questions are asked in a software tester interview for freshers?
Basics such as what a test case is, types of testing, the software testing life cycle, severity versus priority, and a practical task to write test cases for a simple feature. Interviewers look for logical thinking and attention to detail more than tool knowledge.
What do QA engineer interview questions focus on?
QA engineer interviews add automation: framework design, page object patterns, flaky test fixes, API testing, CI integration and often a short coding or code review exercise, on top of testing fundamentals.
What is a good answer to 'how would you test a pen'?
Ask about requirements and users first, then cover function (writing, ink flow), boundaries (temperature, pressure, surfaces), durability, safety, usability and packaging. The interviewer wants a structured approach, not a perfect list.
Do QA tester interviews include a practical test?
Usually. Common formats are writing test cases for a form or feature, finding seeded bugs in a demo app, writing bug reports, or for QA engineers, writing or reviewing an automated test.
What quality assurance interview questions apply outside software?
In manufacturing or contact center QA, questions focus on standards, sampling, inspection or call evaluation criteria, calibration, root cause analysis and giving feedback. Software QA questions focus on test design, bug reporting and automation.