50 Manual Testing Interview Questions and Answers

Manual testing interviews are mostly about vocabulary and thinking. The vocabulary is a fixed set of distinctions (severity vs priority, smoke vs sanity, verification vs validation) that you either know or don’t. The thinking is whether you can take something in front of you, a login page, a pen, an elevator, and turn it into a list of tests that would actually find bugs. This page has the 50 questions that come up most, grouped from fundamentals to scenarios, with the answer an interviewer wants to hear and, where it differs, what an experienced tester should add.

The short answer: Manual testing interviews cover five areas:

• Fundamentals: what testing is, QA vs QC, verification vs validation, SDLC vs STLC.
• Test design: test case vs scenario, boundary value analysis, equivalence partitioning, decision tables, and how you’d test a specific thing.
• Levels and types: unit to acceptance, smoke vs sanity, regression vs retesting, black box vs white box.
• Bugs: life cycle, severity vs priority, what a good bug report contains.
• Process: agile testing, entry and exit criteria, traceability, coverage, when to stop.

Know the distinctions cold and practise testing something out loud, and most of the 50 below are covered.

Fundamentals

1. What is software testing?

Checking whether software does what it’s supposed to and doesn’t do what it isn’t, in order to find defects before users do and to give the team information about quality and risk. Say the second half; testing isn’t only about finding bugs, it’s about giving people enough confidence to ship.

2. What’s the difference between QA, QC and testing?

Quality assurance is process-focused and preventive: standards, reviews, making sure the way we build things produces quality. Quality control is product-focused and detective: checking the thing that was built. Testing is the main activity within QC. In practice “QA” is used as a job title for testers; know the textbook distinction anyway.

3. What’s the difference between verification and validation?

Verification: are we building the product right? Reviews, walkthroughs, inspections, checking against the spec. Validation: are we building the right product? Actually running it and checking it meets the user’s need. Static vs dynamic is the other way to say it.

4. What is SDLC vs STLC?

The software development life cycle is the whole process: requirements, design, build, test, deploy, maintain. The software testing life cycle is the testing part in detail: requirement analysis, test planning, test case design, environment setup, execution, and closure. Each STLC phase has entry criteria, activities, and deliverables.

5. What’s the difference between a test plan and a test strategy?

A strategy is the organisation-level or programme-level approach: what types of testing we do, tools, environments, roles. It changes rarely. A test plan is project-specific: scope, what’s in and out, schedule, resources, risks, entry and exit criteria, deliverables. The plan follows the strategy.

6. What are the seven principles of testing?

Testing shows the presence of defects, not their absence; exhaustive testing is impossible; test early; defects cluster; the pesticide paradox (the same tests stop finding new bugs); testing is context-dependent; absence of errors is a fallacy (a bug-free product nobody wants is still a failure). Freshers get asked to list them; experienced testers get asked for an example of one.

7. What is the pesticide paradox, and what do you do about it?

Running the same tests repeatedly stops finding new bugs, because the code paths they cover have been fixed. You review and update the test set regularly, add exploratory sessions, and vary the data.

8. What is static testing vs dynamic testing?

Static: examining artefacts without executing code. Requirement reviews, design reviews, code walkthroughs, static analysis. Dynamic: running the software. Static testing finds defects earlier and cheaper; most teams under-invest in it.

Test design

9. What’s the difference between a test scenario, a test case, and a test script?

A scenario is a one-line “what to test”: “Verify user can log in with valid credentials.” A test case is the detailed “how”: preconditions, steps, test data, expected result. A script is the automated version. Scenarios are good for coverage discussions; cases are what you execute.

10. What does a good test case contain?

ID, title, preconditions, steps (numbered, one action each), test data, expected result per step or at the end, actual result, status, and a link to the requirement. Keep steps atomic and the expected result specific (“error message ‘Invalid password’ appears below the field”, not “error shown”).

11. What is boundary value analysis?

Testing at the edges of valid ranges, because that’s where off-by-one bugs live. For an age field accepting 18 to 60: test 17, 18, 19, 59, 60, 61. Add 0, negative, blank, decimals, and very large numbers as robustness cases.

12. What is equivalence partitioning?

Dividing input into classes where the system should behave the same, and testing one value from each class instead of every value. For the age field: one value below 18, one in 18 to 60, one above 60, and one non-numeric. It cuts the number of tests without losing coverage.

13. What is a decision table, and when do you use it?

A table of conditions and the resulting actions, used when the outcome depends on combinations of inputs. A discount that depends on membership status, order value and coupon code has eight combinations; the table makes sure you test each. Use it whenever the spec has “if… and… then”.

14. What is state transition testing?

Testing a system that behaves differently depending on its current state: an order that can be placed, paid, shipped, delivered, cancelled, or refunded. You test valid transitions (paid to shipped), invalid ones (delivered to cancelled), and events that shouldn’t change state.

15. What is error guessing?

Using experience to guess where bugs are likely: empty inputs, maximum lengths, special characters, double-clicking submit, back button after a form, changing the URL parameters, the same user logged in twice. It’s unstructured, which is why you do it in addition to the structured techniques, not instead.

16. How would you test a login page?

Group your answer so the interviewer can see structure.

Positive: valid credentials; remember-me works across sessions; redirect to the page the user was trying to reach.

Negative: wrong password; wrong username; both blank; one blank; correct credentials with leading or trailing spaces; case sensitivity of username and password; maximum length exceeded; account locked; account not yet verified.

Security: SQL injection and script tags in both fields; password masked; error message doesn’t say which field was wrong; lockout after N failures; session expires; back button after logout doesn’t show the logged-in page; password not in the URL or logs.

Usability and accessibility: tab order; Enter submits; error messages are readable; screen reader labels; works on mobile widths.

Experienced tester adds: rate limiting on the login endpoint, behaviour when the auth service is down, and what happens to an in-progress session when the password is changed elsewhere.

17. How would you test a pen (or a lift, or a coffee machine)?

They’re checking whether you can structure without a spec. Do: functional (does it write, on which surfaces, how long), usability (grip, weight, cap), reliability (drop it, leave it uncapped), stress (write continuously), environmental (heat, cold, water), safety (cap choking hazard), and compatibility (refills). Say out loud that you’d want to know the requirements first; that’s the point.

18. How do you decide what to test when there isn’t time to test everything?

Risk-based: what’s most likely to break, and what would hurt most if it did. New and changed code first, then the most-used paths, then integrations, then the rest. Say what you’re not testing and get it agreed in writing.

19. What is a traceability matrix?

A table mapping requirements to the test cases that cover them, so you can see which requirements have no tests and which tests have no requirement. It’s how you answer “have we tested everything in the spec” with evidence.

20. What is test coverage, and what are its limits?

The proportion of something (requirements, code, risks) covered by tests. Requirements coverage is what manual testers usually report. The limit: 100 percent coverage of the spec says nothing about the things the spec forgot.

Levels and types of testing

21. What are the levels of testing?

Unit (a single function, by developers), integration (components together), system (the whole product against requirements), and acceptance (by or for the customer, against their needs). Manual testers mostly work at system and acceptance level; know what happens at the others.

22. What’s the difference between smoke and sanity testing?

Smoke: wide and shallow, on every new build, “is this build testable at all?” Sanity: narrow and deep, after a specific change, “did the fix work and did it break the area around it?” Smoke is usually a fixed scripted set; sanity is targeted.

23. What’s the difference between regression and retesting?

Retesting: running the failed test again after the bug is fixed, to confirm the fix. Regression: running tests around the change to confirm nothing else broke. Retesting is about the bug; regression is about everything else.

24. What’s the difference between black box, white box and grey box testing?

Black box: testing from the outside with no knowledge of the code, from requirements. White box: testing with the code in view, covering paths and branches, mostly by developers. Grey box: partial knowledge, such as knowing the database schema or API contract, which lets a tester design better tests without reading source.

25. What’s the difference between functional and non-functional testing?

Functional: does it do the right thing. Non-functional: how well. Performance, load, stress, security, usability, accessibility, compatibility, reliability, localisation. Interviewers like it when you can name a specific non-functional test you’ve done.

26. What’s the difference between positive and negative testing?

Positive: valid inputs, expected paths, confirming it works. Negative: invalid inputs, unexpected paths, confirming it fails gracefully. Freshers over-index on positive tests; most bugs are found by negative ones.

27. What’s the difference between ad hoc, exploratory and monkey testing?

Ad hoc: unplanned testing without documentation, based on intuition. Exploratory: simultaneous learning, test design and execution, usually time-boxed with a charter (“explore the checkout flow with unusual quantities”) and notes taken. Monkey: random inputs with no understanding, useful for finding crashes. Exploratory is the one to talk about with respect; it’s a skill.

28. What is user acceptance testing?

Testing by end users or their representatives against real business scenarios, to confirm the software is fit for purpose before go-live. Alpha (in-house) and beta (with real customers) are variants. The tester’s role is usually to prepare scenarios and support users, not to execute.

29. What is compatibility testing?

Checking the software works across the browsers, devices, operating systems, screen sizes and versions it claims to support. Pick the matrix from analytics (what users actually use), not from what’s convenient.

30. What is localisation vs internationalisation testing?

Internationalisation: is the product built to support many locales (no hard-coded strings, date and number formats adapt, text expansion doesn’t break layouts). Localisation: is a specific locale correct (the German translation, currency, date format, right-to-left layout for Arabic).

Bugs

31. Explain the bug life cycle.

New → Assigned → Open (in progress) → Fixed → Retest → Verified → Closed. Branches: Reopened (retest failed), Rejected (not a bug or works as designed), Duplicate, Deferred (valid, fix later), Not Reproducible. Say who moves the bug at each step: tester logs and retests, lead or PM triages, developer fixes.

32. What’s the difference between severity and priority? Give examples.

Severity is impact on the system, set by the tester. Priority is urgency of fix, set by product or lead.

Case	Severity	Priority
App crashes on launch for all users	High	High
Company name misspelled on homepage	Low	High
Year-end report crashes, used once a year, workaround exists	High	Low
Slight misalignment on a rarely used settings page	Low	Low

33. What does a good bug report contain?

Title (one line, specific: “Checkout button unresponsive when cart has more than 20 items on Safari 17”), environment (build, browser, OS, device), steps to reproduce (numbered, minimal), expected result, actual result, severity, priority, screenshots or video, logs if you have them, and how often it reproduces. The test of a good report: a developer can reproduce it without asking you anything.

34. What do you do when a developer says “it’s not a bug, it’s a feature”?

Go back to the requirement. If the requirement supports the developer, close it and raise a requirement query if you still think the behaviour is wrong for users. If the requirement supports you, escalate with the reference. If there’s no requirement, raise it with the product owner; that’s a gap, not an argument.

35. What do you do when you can’t reproduce a bug?

Note exactly what you tried, gather the original environment details, check for data or timing dependencies, ask the reporter for a video or logs, and try on a clean environment. Mark it not reproducible with your notes rather than closing it silently; intermittent bugs are usually real.

36. What is defect leakage, and how do you reduce it?

Bugs found in production that should have been found in testing, usually expressed as a percentage of total defects. Reduce it by reviewing every leaked bug for the test that would have caught it, adding that test, and looking at the category (untested area, environment difference, data) rather than the instance.

37. What is bug triage?

A regular meeting where product, development and test review new bugs and agree severity, priority, owner and target release. Testers bring the evidence; product decides priority.

38. What is the difference between error, defect and failure?

An error is a human mistake (the developer misread the spec). A defect (or bug) is the flaw in the code that resulted. A failure is what the user sees when the defect executes. Not every defect causes a failure; some code paths never run.

Process

39. What does a tester do in an agile team?

Joins refinement to ask questions early, writes acceptance criteria with the product owner, tests stories within the sprint rather than after it, pairs with developers, does exploratory testing on each increment, maintains the regression set, and reports at the daily stand-up like everyone else. The shift from “testing phase” to “testing activity” is the point to make.

40. What are entry and exit criteria?

Entry: what must be true before testing starts (build deployed, smoke passed, test data loaded, test cases reviewed). Exit: what must be true before testing is declared done (all planned tests executed, no open high-severity bugs, coverage targets met, sign-off obtained). They stop testing starting too early and ending too vaguely.

41. When do you stop testing?

When the exit criteria are met, or when the risk of the remaining untested areas is accepted by someone with the authority to accept it. Never “when we run out of time” without saying what wasn’t tested.

42. What is a test environment, and what problems do you see with them?

The hardware, software, network and data on which tests run. Common problems: it doesn’t match production (different versions, less data, missing integrations), it’s shared and someone else’s test changes your data, and it’s down. Say how you’d handle each.

43. How do you manage test data?

Identify what each test needs, create it in a repeatable way (scripts, fixtures, or a data setup API), isolate it per test or per tester so runs don’t collide, mask production data if you use it, and reset between cycles.

44. What metrics do you report?

Test cases planned, executed, passed, failed, blocked; defects by severity and status; defect density; defect leakage; requirements coverage. Pick the ones the audience will act on; nobody needs all of them.

45. What is risk-based testing?

Prioritising tests by the probability of failure and the impact if it fails. New code, complex code, code with a history of bugs, and code on the money path get tested first and deepest. It’s how you make “we can’t test everything” defensible.

Scenarios

46. The release is tomorrow and you’ve found a high-severity bug. What do you do?

Report it immediately with full evidence, state the impact clearly, propose options (fix and retest tonight, ship with a workaround and a known-issue note, delay), and let the people who own the decision make it. Your job is to make the risk visible, not to make the call alone.

47. Developers keep marking your bugs as “cannot reproduce”. What do you change?

Improve the reports: exact steps, environment, data, screenshots, a video. Reproduce it twice yourself before logging. Offer to show them on your machine. If it’s environmental, say so in the report. Most “cannot reproduce” is a report problem, not a developer problem.

48. You’ve been given a feature to test with no requirements. What do you do?

Ask for whatever exists: the ticket, a mock-up, a conversation with the product owner or developer. Write down what you think it should do and get that confirmed. Test against that, and log anything that seems wrong as a question rather than a bug until the behaviour is agreed.

49. How do you handle a disagreement with a developer about a bug?

Stick to evidence: steps, expected vs actual, the requirement. Ask them to show you why it’s correct. If you still disagree, take it to triage rather than arguing in the ticket. Most disagreements are actually unclear requirements.

50. What would you automate first if the team gave you a budget for it?

The smoke suite (it runs on every build), then the regression cases that are stable and boring, then data setup. Not new features, not exploratory testing, not anything that changes weekly. Say what you’d keep manual and why; that shows you understand what automation is for.

Preparing the night before

1. Write the severity vs priority table from memory, with examples.
2. Say the smoke vs sanity, regression vs retesting, and verification vs validation distinctions out loud in one sentence each.
3. Test a login page out loud, in the four groups above, in under three minutes.
4. Draw the bug life cycle.
5. Have one bug story: what it was, how you found it, how you reported it, what happened.

Where Tailr fits

Manual testing job listings vary widely: some want pure exploratory skill, some want test-case writing, some want SQL and API basics, some want a path to automation. Tailr tailors your resume to the specific listing you’re viewing, so the testing types and tools that role names are the ones your resume leads with. For the tools side, see best tools for QA and software testing; if the role touches APIs, 50 API testing interview questions covers that round; and for the non-technical questions, 40 behavioral interview questions with sample answers. Try Tailr to line the resume up with the role before the interview.

Related guides

• What Is Software Testing? Types, Levels and Methods Explained
• What Is API Testing? Types, Tools and How to Start
• QA Engineer vs. SDET: Differences, Salary and Which to Choose
• Top QA Interview Questions (and How to Answer Them)
• Test Case vs Test Scenario vs Test Plan: Differences With Examples

Conclusion

Manual testing interviews are won on two things: knowing the distinctions precisely, and being able to turn anything into a structured list of tests out loud. Learn the vocabulary until it’s automatic, practise testing a login page and an everyday object with the positive, negative, security and usability groups, be able to draw the bug life cycle and explain severity versus priority with examples, and bring one good bug story. That covers the 50 above and most of what any interviewer will add.