Manual Testing Interview Questions & Answers
These are the manual testing questions QA engineers are asked most, in fresher and experienced interviews alike — and the foundation that automation interviews build on. Each answer is short enough to say out loud, with an example where it helps, and a link to the full topic. For the complete learning path, start with The Complete Manual Testing Tutorial.
Testing Fundamentals (Q1–5)
Q1. What is manual testing?
Testing software by hand — executing test cases as a user would, comparing actual with expected results, and reporting defects — without automation scripts. It's essential for new features, exploratory, usability and acceptance testing.
Learn more: Manual & Automation Testing
Q2. Manual vs automation testing?
- Manual — best for exploratory, usability, ad-hoc and one-off testing, and features that change often.
- Automation — best for repetitive, stable, high-volume checks: regression, smoke, data-driven and cross-browser runs.
They complement each other: good automation starts from good manual test design.
Learn more: Manual vs Automation Testing
Q3. QA vs QC?
- QA (Quality Assurance) — process-oriented; prevents defects (reviews, standards, process improvement).
- QC (Quality Control) — product-oriented; finds defects (testing).
Learn more: QA Concepts & Glossary
Q4. Verification vs validation?
- Verification — "Are we building the product right?" Reviews, walkthroughs and inspections of documents and code, usually without running the software.
- Validation — "Are we building the right product?" Running the software to confirm it meets user needs.
Learn more: QA Concepts
Q5. Testing vs debugging?
Testing finds and reports defects — done by testers. Debugging locates the root cause in the code and fixes it — done by developers.
Functional Testing Types (Q6–11)
Q6. Smoke vs sanity testing? ⭐
- Smoke — broad and shallow: is this new build stable enough to test at all? (Login works, main pages load, core flow completes.)
- Sanity — narrow and deep: does this specific fix or change work, and does its immediate area still behave?
Learn more: Smoke vs Sanity Testing
Q7. What is regression testing?
Re-testing existing functionality after changes to make sure nothing that used to work is now broken. It's the best candidate for automation because it's repeated for every release.
Learn more: Functional Testing Types
Q8. Retesting vs regression testing?
- Retesting — checks that a specific defect is fixed, using the same steps that failed.
- Regression — checks that the fix (or any change) didn't break anything else.
Example: a checkout bug is fixed. Retesting confirms checkout now works; regression confirms cart, payment and order history still work.
Q9. What is Build Verification Testing (BVT)?
Another name for smoke testing: a fixed set of core checks run on every new build. If it fails, the build goes back to development without further testing.
Q10. What is User Acceptance Testing (UAT)?
The final testing phase, done by business users or customers, to confirm the software meets their needs in realistic scenarios before go-live. QA usually supports UAT rather than performing it.
Q11. In what order do smoke, retesting, sanity and regression usually run?
For a new build: smoke (is it testable?) → retesting of fixed defects → sanity around the changes → regression of the wider application.
Defect Management (Q12–17)
Q12. Severity vs priority? ⭐
- Severity — the defect's technical impact; usually set by the tester.
- Priority — how urgently it should be fixed; decided by the product owner or triage.
Learn more: Severity vs Priority — All 4 Combinations
Q13. Give examples of mismatched severity and priority.
- High severity, low priority: the app crashes when exporting a report in an old format that only a few internal users need.
- Low severity, high priority: the company name is misspelled in the home-page logo — nothing is broken, but every visitor sees it.
Q14. What is the defect life cycle?
New → Assigned → Open (in progress) → Fixed → Retest → Closed, with Reopened if the retest fails.
Other outcomes: Rejected, Duplicate, Deferred, Cannot Reproduce. Names vary by team and tool.
Learn more: Defect & Bug Management
Q15. Bug leakage vs bug release?
- Bug leakage — a defect that testing missed and users found in production.
- Bug release — a known defect released on purpose, with business approval, usually low impact and documented in release notes.
Q16. What is defect triage?
A meeting — typically the product owner, QA lead and development lead — where new defects are reviewed to confirm validity, set priority, assign owners and decide which release they go into.
Learn more: Defect Management in Jira
Q17. What is a showstopper?
A defect so severe that it blocks further testing or makes release impossible — for example, login failing for all users or payments failing. It's fixed immediately, often with a hotfix.
Agile & Process (Q18–22)
Q18. What is Agile?
An iterative approach that delivers working software in short cycles (sprints, usually 1–4 weeks), with continuous feedback and testing throughout rather than at the end.
Learn more: Agile & Scrum for Testers
Q19. Agile vs Waterfall?
- Waterfall — sequential phases; testing happens after development is complete; changes are expensive.
- Agile — incremental delivery; testing happens every sprint; change is expected.
Learn more: Agile vs Waterfall
Q20. What are the Scrum ceremonies — and a tester's role in each?
- Sprint Planning — estimate testing effort, clarify acceptance criteria.
- Daily Scrum — share testing progress and blockers.
- Sprint Review — help demo completed, tested work.
- Retrospective — suggest process improvements.
Backlog refinement isn't a formal ceremony, but it's where testers add the most value — asking "what if…?" before development starts.
Q21. SDLC vs STLC?
SDLC covers building software end to end (requirements, design, development, testing, deployment, maintenance). STLC is the testing process within it.
Learn more: SDLC & STLC
Q22. What are the STLC phases?
Requirement analysis → test planning → test case design → test environment setup → test execution → test closure.
Each has entry and exit criteria; for example, execution starts when the build passes smoke testing and the environment is ready.
Test Design & Documentation (Q23–27)
Q23. Test plan vs test strategy?
- Test strategy — the high-level, usually organization- or program-wide approach: levels, types, tools, environments.
- Test plan — project- or release-specific: scope, schedule, resources, risks, entry and exit criteria.
Learn more: Test Documentation & Planning
Q24. What is a Requirement Traceability Matrix (RTM)?
A table mapping each requirement to its test cases (and their results and defects). It proves coverage and shows exactly which tests to re-run when a requirement changes.
Q25. What is boundary value analysis? ⭐
Testing at the edges of valid ranges, where defects cluster.
For "age must be 18–60", test 17, 18, 19 and 59, 60, 61.
Learn more: Test Design Techniques
Q26. What is equivalence partitioning?
Dividing inputs into groups that should behave the same, and testing one value from each.
For the same age rule:
- Below 18 — e.g. 10
- 18–60 — e.g. 35
- Above 60 — e.g. 70
It cuts the number of tests without losing coverage — and pairs naturally with boundary values.
Q27. Black box vs white box vs gray box?
- Black box — tests behavior without knowing the code (most manual testing).
- White box — tests internal logic and code paths (mostly developers, unit tests).
- Gray box — partial knowledge, such as database structure or API contracts, used to design better tests.
Learn more: Black, White & Gray Box Testing
Non-Functional Testing & QA Concepts (Q28–30)
Q28. Load vs stress testing?
- Load — performance under expected and peak user volumes (response time, throughput).
- Stress — beyond expected capacity, to find the breaking point and check the system recovers gracefully.
Learn more: Non-Functional & Performance Testing
Q29. Alpha vs beta testing?
- Alpha — done internally (testers, internal users) before release, in a controlled environment.
- Beta — done by a limited group of real users in their own environments before general release.
Q30. What is the pesticide paradox — and when do you stop testing?
The pesticide paradox: running the same tests repeatedly finds fewer new defects over time, so test cases must be reviewed and updated.
It's one of the seven testing principles — along with "exhaustive testing is impossible" and "defects cluster together".
Stop testing when the exit criteria are met — planned tests executed, no open critical or high defects, agreed coverage reached and remaining risks accepted — or when time runs out, in which case the untested risk is reported explicitly.
Practice these with realistic tasks in the Manual Testing Simulator, then move on to Scenario-Based Testing Questions.
From the Interview Room
Before any automation, my work on each project started with the requirement: understanding the business flow, identifying scenarios, writing test cases and getting them reviewed. On Canolog, where sales, inventory, finance, service and parts all connect, that analysis is what found the gaps between modules. Execution was tracked in TestRail and defects in Jira. On Apkope, prospect and customer data arrives from email, phone, social media and chatbots, so test scenarios had to cover every channel that feeds the same records. Answer with examples from your own project wherever you can.
📚 Official documentation: ISTQB Glossary of testing terms
FAQs
Which manual testing questions are asked most?
Smoke vs sanity, retesting vs regression, severity vs priority, the defect life cycle, STLC phases, boundary value analysis and equivalence partitioning.
Are these questions asked in automation interviews too?
Yes — especially the first round. Automation interviewers expect strong testing fundamentals.
How should I answer a definition question?
Give a one-line definition, then an example from your project. The example is what makes the answer memorable.
Should freshers learn the seven testing principles?
Yes — they come up often, especially the pesticide paradox, defect clustering and "exhaustive testing is impossible".
What comes after these questions?
Scenario-based questions ("What would you do if…?") and "How would you test X?" questions — see the next-step links above.
