Whether you are a fresher facing your first QA interview or a tester with a few years of experience, the same core manual testing interview questions come up again and again. Interviewers want to see that you understand testing fundamentals, can design good test cases, report defects clearly and think through real-world scenarios.

This guide groups 60 frequently asked questions into five sections, each with a short answer you can expand in your own words. Read the answer, then practise saying it aloud with an example from your own project or practice work.

Key takeaways

• Master the basics first: STLC, levels and types of testing, and the seven testing principles.
• Be ready to apply test design techniques such as boundary value analysis on the spot.
• Severity vs priority and the bug life cycle are asked in almost every round.
• Scenario questions test your thinking, so answer in a structured way.

Basic manual testing interview questions (1–10)

1. What is software testing?
It is the process of evaluating a product to find defects and to check that it meets requirements and user needs. It reduces the risk of failure in production.

2. What is the difference between verification and validation?
Verification asks “are we building the product right?” through reviews and walkthroughs. Validation asks “are we building the right product?” by executing the software.

3. What is manual testing?
Executing tests by hand, without automation scripts, using a tester’s judgement. It suits exploratory, usability and ad-hoc testing and features that change often.

4. What is the difference between SDLC and STLC?
SDLC covers the whole software development process from requirements to maintenance. STLC is the set of testing activities that runs within it.

5. What are the phases of STLC?
Requirement analysis, test planning, test case development, test environment setup, test execution and test closure.

6. What are error, defect and failure?
An error is a human mistake. It can introduce a defect (bug) in the code. When defective code executes and the system behaves incorrectly, that is a failure.

7. Name the seven testing principles.
Testing shows the presence of defects; exhaustive testing is impossible; early testing saves time and money; defects cluster together; tests wear out (pesticide paradox); testing is context dependent; and the absence-of-defects fallacy.

8. What are the levels of testing?
Unit (component), integration, system and acceptance testing.

9. Functional vs non-functional testing?
Functional testing checks what the system does against requirements. Non-functional testing checks how well it does it: performance, security, usability, compatibility.

10. What are black box, white box and grey box testing?
Black box tests behaviour without seeing the code, white box uses knowledge of internal code and logic, and grey box combines partial internal knowledge with black box tests.

Test design questions (11–18)

11. Test scenario vs test case?
A scenario is a high-level “what to test”, such as “verify login”. A test case is detailed: preconditions, steps, data and expected result.

12. What fields does a good test case have?
ID, title, preconditions, steps, test data, expected result, actual result, status and priority, plus a link to the requirement.

13. Explain equivalence partitioning.
Divide inputs into groups that should behave the same and test one value from each. For an age field accepting 18–60, the partitions are below 18, 18–60 and above 60.

14. Explain boundary value analysis.
Defects often hide at edges, so test values on and around boundaries. For 18–60, test 17, 18, 60 and 61 (add 19 and 59 for three-value BVA).

15. When do you use decision table testing?
When output depends on combinations of conditions, for example a discount that depends on membership type and cart value. Each column is a rule to test.

16. What is state transition testing?
Testing how a system moves between states on events. Example: an account locks after three wrong PIN attempts.

17. What is exploratory testing?
Simultaneous learning, test design and execution, usually time-boxed with a charter. It finds issues scripted tests miss.

18. What is an RTM?
A Requirement Traceability Matrix maps each requirement to its test cases and defects, proving coverage and showing the impact of changes.

Defect management questions (19–26)

19. Explain the bug life cycle.
New → Assigned → Open → Fixed → Retest → Verified → Closed. A bug can also be Reopened, Rejected, Duplicate or Deferred. Exact states depend on the tool and team.

20. Severity vs priority?
Severity is the technical impact on the system. Priority is how urgently the business wants it fixed.

21. Give examples of mismatched severity and priority.
High severity, low priority: a crash in a rarely used legacy report. Low severity, high priority: the company name misspelt on the home page.

22. What makes a good bug report?
A clear title, environment and build, numbered steps, test data, expected vs actual result, screenshots or video, logs, and severity.

23. A developer cannot reproduce your bug. What do you do?
Re-check it on the latest build, share exact data, environment and a recording, attach logs, and reproduce it together if needed.

24. What is defect leakage?
Defects missed in a testing phase and found later, often by users in production. Teams track it to improve coverage.

25. Retesting vs regression testing?
Retesting confirms a specific fixed defect now works. Regression testing checks that the change did not break existing features.

26. Smoke vs sanity testing?
Smoke testing is a broad, shallow check that a new build is stable enough to test. Sanity testing is a narrow, focused check of a specific fix or area.

Type	Scope	When	Goal
Smoke	Broad, shallow	Every new build	Is the build testable?
Sanity	Narrow, focused	After a minor fix	Does this area work?
Retesting	Specific defects	After a bug fix	Is the bug fixed?
Regression	Existing features	After any change	Did anything else break?

Process and Agile questions (27–33)

27. What does a test plan contain?
Scope, objectives, approach, resources, schedule, environments, entry and exit criteria, risks and deliverables.

28. What are entry and exit criteria?
Entry criteria must be met before testing starts, such as a stable build. Exit criteria define when to stop, such as all critical tests passed and no open blockers.

29. What is a tester’s role in Scrum?
Join refinement, clarify acceptance criteria, test stories within the sprint, raise risks early and support the definition of done.

30. Alpha vs beta testing?
Alpha testing happens at the developer’s site with internal users. Beta testing is done by real users in their own environment before full release.

31. What is UAT?
User Acceptance Testing, where business users confirm the system supports real workflows before go-live.

32. Static vs dynamic testing?
Static testing examines work products without executing code, such as reviews. Dynamic testing executes the software.

33. When do you stop testing?
When exit criteria are met and remaining risk is acceptable to stakeholders, not simply when time runs out.

Scenario-based questions (34–40)

34. How would you test a login page?
Valid and invalid credentials, empty fields, password masking, lockout after failed attempts, “forgot password”, session timeout, SQL injection attempts and browser compatibility.

35. How would you test a search box?
Exact, partial and no-match terms, special characters, very long input, case sensitivity, sorting and filters, and response time.

36. There are no requirement documents. What now?
Talk to the product owner and developers, study similar products, explore the application, and write down assumptions to get them confirmed.

37. You cannot run all tests before release. What do you do?
Use risk-based testing: prioritise critical business flows, recent changes and defect-prone areas, and report what was not covered.

38. A developer says your bug is “not a bug”. How do you respond?
Refer to the requirement or acceptance criteria, show evidence calmly, and involve the product owner if you still disagree.

39. How would you test a payment flow?
In a test environment: successful payment, declined card, timeouts, double clicks, back button, refunds, order status updates and confirmation emails.

40. Is manual testing still relevant?
Yes. Exploratory, usability and new-feature testing need human judgement, and good manual skills make you a better automation engineer later.

More manual testing interview questions (41–60)

41. What are stubs and drivers?
Dummy modules used in integration testing. A stub stands in for a lower-level module that is not ready yet (used in top-down testing). A driver calls the module under test when its higher-level caller is not ready (used in bottom-up testing).

42. What are big-bang, top-down and bottom-up integration testing?
Big-bang joins all modules at once and tests them together. Top-down starts with the top modules and uses stubs for the rest; bottom-up starts with the lowest modules and uses drivers. Incremental approaches make it much easier to find which module caused a defect.

43. What is end-to-end testing?
Testing a complete user journey across all connected systems with realistic data. Example: search a product, add it to the cart, pay, and receive the confirmation email.

44. What is positive and negative testing?
Positive testing checks that the system works with valid input. Negative testing checks that it handles invalid input safely, for example typing letters in a phone number field should show a clear error, not crash the form.

45. What is a latent defect, and what is a masked defect?
A latent defect exists in the code but has not caused a failure yet because its trigger has not happened (for example a leap-year date bug). A masked defect is hidden by another defect and appears only after the first one is fixed.

46. What is defect cascading?
When one defect triggers other defects further along. For example, a wrong tax calculation also produces wrong invoice totals and wrong monthly reports.

47. What is a show-stopper defect?
A defect so serious that testing or release cannot continue, such as the app crashing on launch or every payment failing. It is fixed before anything else.

48. What is the age of a defect?
The time between when a defect was found (or introduced) and when it was fixed and closed. A high average defect age means slow feedback between testers and developers.

49. What is DRE (Defect Removal Efficiency)?
DRE = defects found before release ÷ (defects found before release + defects found in production) × 100. If testing found 90 defects and users found 10 more, DRE is 90%.

50. What is the pesticide paradox?
Running the same tests again and again stops finding new bugs, just as pests become resistant to the same pesticide. Review and update test cases regularly, use new test data and add exploratory testing.

51. What is exhaustive testing, and why is it not possible?
Testing every possible input and path. Even a small form has millions of combinations, so we choose tests with risk analysis and techniques like equivalence partitioning and boundary value analysis.

52. What is risk-based testing?
Prioritising testing by how likely a failure is and how much damage it would cause. Payments, login and data security get the most test effort; low-risk screens get less.

53. What is fuzz testing?
Sending random, invalid or unexpected data to an application to find crashes, hangs and security holes. It is usually automated with fuzzing tools.

54. What is cross-browser and responsive testing?
Cross-browser testing checks that the site works the same on Chrome, Firefox, Safari and Edge. Responsive testing checks that the layout adapts correctly to mobile, tablet and desktop screen sizes.

55. What is localization testing?
Checking that a version built for a specific language or region is correct: translations, date and currency formats, longer translated text fitting the UI, and right-to-left scripts where needed.

56. What is soak (endurance) testing?
Running the system under normal load for many hours or days to find memory leaks, slow performance degradation and resource exhaustion.

57. What is recovery testing?
Checking how well the system recovers after a crash, network loss or server restart. For example, if the network drops during a payment, the payment should either complete or roll back cleanly.

58. What is a test bed?
The complete environment prepared for testing: hardware, operating system, browsers, database, network setup, tools and test data.

59. What are test deliverables?
The documents and artifacts produced during testing: test plan, test scenarios and cases, traceability matrix, test data, defect reports and the test summary report.

60. When would you choose manual testing over automation?
For exploratory and usability testing, ad-hoc checks, features that change often, and tests run only once or twice. Stable, repetitive regression tests are better automated.

How to prepare effectively

Use the ISTQB Foundation syllabus to strengthen terminology, and follow the software testing roadmap to see what to learn next. Then take the free daily QA practice test to check your recall under time pressure.

FAQs

Are manual testing interview questions different for freshers?

Freshers get more theory and definitions. Experienced testers get more scenario, process and project questions.

Do I need automation skills for a manual QA role?

Not always, but basic SQL, API testing with Postman and awareness of Selenium make your profile much stronger.

How should I answer theory questions?

Give a one-line definition, then a short example from a project or a familiar app. Examples show real understanding.

Is ISTQB certification mandatory?

No. It helps with terminology and some employers value it, but practical skills and clear communication matter more.

How long does it take to prepare?

With daily practice, two to three weeks is enough to revise these topics confidently if you already know the basics.

Conclusion

Manual testing interview questions reward clear thinking more than memorised definitions. Revise these 60 answers, attach a real example to each, and practise scenario questions aloud. When you feel ready, browse the daily QA jobs list and start applying — every interview makes the next one easier.