Top 35 Manual Testing Interview Questions and Answers

Manual testing remains a core skill even in an increasingly automated world. Exploratory testing, usability evaluation, and test case design all require human judgment that automation cannot fully replace. Whether you're preparing for your first QA role or interviewing for a senior manual tester position, this guide covers the questions you're likely to face — with answers that show real understanding, not just definitions.

1. What is the difference between verification and validation in software testing?

Verification checks whether you're building the product correctly — it reviews documents, designs, code, and plans against specifications without executing the software. Examples include requirements reviews, code reviews, and design inspections. Validation checks whether you're building the correct product — it involves executing the software and confirming it meets user needs and business requirements. The short version: verification is "did we build it right?" and validation is "did we build the right thing?"

2. What is a test case, and what are its essential components?

A test case is a documented set of conditions, steps, and expected results designed to verify a specific aspect of software behavior. Essential components include: a unique test case ID, a clear title describing what is being tested, preconditions (what must be true before the test runs), test steps (sequential actions to take), expected results for each step, actual results (filled in during execution), test data needed, environment details, and pass/fail status. Well-written test cases can be executed by someone unfamiliar with the feature and produce consistent results.

3. Explain equivalence partitioning with an example.

Equivalence partitioning divides input data into groups (partitions) where all values in a group are expected to behave the same way. Instead of testing every value, you test one representative from each partition. Example: for a field that accepts ages between 18 and 65, the partitions are: below 18 (invalid), 18–65 (valid), above 65 (invalid). You test one value from each partition — say, 10 (invalid), 35 (valid), and 70 (invalid) — rather than testing every possible age. This reduces the number of test cases while maintaining reasonable coverage.

4. What is boundary value analysis?

Boundary value analysis tests the values at the edges of each equivalence partition, because bugs cluster around boundaries. For the age example (18–65), boundary values are: 17 (just below lower bound), 18 (lower bound), 65 (upper bound), 66 (just above upper bound). Testing these four values catches common off-by-one errors in comparison logic. In practice, combine BVA with equivalence partitioning — test the boundaries of each partition plus one representative from the middle.

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

A test strategy is a high-level document describing the overall approach to testing for the entire organization or program — testing types, tools, standards, and processes. It rarely changes. A test plan is a project-specific document that outlines the scope, objectives, resources, schedule, approach, risks, and exit criteria for a particular testing effort. Test plans are created per release or project and derived from the test strategy. In smaller organizations, the distinction is often blurred and both concepts merge into a single "test plan" document.

6. What is exploratory testing, and how does it differ from scripted testing?

In scripted testing, test cases are pre-written and testers follow them step by step. In exploratory testing, the tester simultaneously designs and executes tests, using their domain knowledge and intuition to guide exploration of the system. Exploratory testing is not ad hoc — it's structured through charters (defined scope and objectives for a time-boxed session) and session-based test management. It's most effective for finding unexpected behavior, usability issues, and edge cases that scripted tests miss. The two approaches are complementary, not competing.

7. Explain the bug lifecycle from discovery to closure.

1. New — tester logs the defect with steps to reproduce, expected vs. actual behavior, severity, and priority
2. Assigned — a developer or triage team assigns it to the responsible developer
3. Open/In Progress — developer investigates and works on the fix
4. Fixed/Resolved — developer marks it fixed and updates the build number
5. Retest — tester verifies the fix in the correct build
6. Closed — if fix is verified, the defect is closed
7. Reopened — if the fix doesn't work or the defect recurs, it's reopened
8. Deferred — if the fix is postponed to a future release
9. Rejected/Not a Bug — if the behavior is by design or can't be reproduced

8. What is the difference between severity and priority?

Severity describes the technical impact of a defect on the system — how broken something is. Priority describes the business urgency of fixing it — how soon it needs to be fixed. A high-severity, low-priority bug: a crash in a rarely used administrative feature. A low-severity, high-priority bug: a typo in the product name on the homepage. Misunderstanding this distinction causes problems in triage meetings — always be clear about which dimension you're discussing.

9. What is regression testing, and when should it be performed?

Regression testing verifies that changes to the software haven't broken existing functionality. It should be performed after every code change — bug fixes, new features, configuration changes, and third-party dependency updates. The regression suite typically includes: all previously failed tests that have been fixed, tests for high-risk or frequently changed areas, smoke tests, and critical path tests. In fast-moving teams, regression testing is automated and runs on every pull request.

10. What is the difference between smoke testing and sanity testing?

Smoke testing (also called build verification testing) is a shallow test of the major functions of a build to determine whether it's stable enough for further testing. It's like checking if the car starts before you take it for a full test drive. Sanity testing is a narrow, focused test performed after receiving a bug fix or new minor feature to verify that a specific area works correctly — you're checking sanity before going deeper. Smoke tests are broader; sanity tests are more focused on a specific change.

11. What are the different levels of testing?

• Unit testing — tests individual functions or components in isolation, typically written by developers
• Integration testing — tests the interaction between components or services
• System testing — tests the complete integrated application against requirements
• Acceptance testing — validates the system meets business requirements and is ready for delivery (includes UAT — User Acceptance Testing)

Each level catches different categories of defects and has different ownership. QA engineers are primarily involved in system and acceptance testing, though good QA teams also review unit test quality.

12. What is a test matrix and when would you use one?

A test matrix (also called a traceability matrix or test coverage matrix) maps test cases to requirements, user stories, or feature areas. It helps verify that every requirement has at least one test case, identifies gaps in coverage, and supports impact analysis when requirements change. You'd use it when requirements are formal and documented (regulatory, enterprise), when demonstrating test coverage to auditors or stakeholders, or when managing a large test suite where it's easy to lose track of what's covered.

13. What is decision table testing?

Decision table testing is a technique for testing systems with complex business rules where multiple conditions combine to produce different outcomes. You list all possible combinations of conditions and the corresponding expected actions in a table. It ensures you test all meaningful combinations, not just the happy path. Useful for things like: insurance eligibility rules, discount calculation logic, access control policies. Decision tables force you to explicitly enumerate combinations that might otherwise be overlooked.

14. What is state transition testing?

State transition testing applies to systems that have distinct states and transitions between them based on events or inputs. Examples: an order management system (new → confirmed → shipped → delivered → returned), a login system (logged out → entering credentials → logged in → locked), a traffic light (red → green → yellow → red). Test cases cover valid transitions, invalid transitions (attempting to go directly from new to shipped), and boundary conditions (entering locked state after exactly 3 wrong passwords).

15. How do you write a good bug report?

A good bug report includes: a clear, specific title (not "Login broken" but "Login fails with 500 error when email contains a plus sign"); steps to reproduce that are minimal and precise; expected behavior and actual behavior; the environment (browser, OS, version); severity and priority; screenshots or screen recordings; and the frequency (does it reproduce every time?). The goal is to give developers everything they need to reproduce and fix the issue without coming back to the tester. Vague bug reports waste developer time and create friction.

16. What is the difference between functional and non-functional testing?

Functional testing verifies that the system does what it's supposed to do — features work correctly according to requirements. Non-functional testing evaluates qualities: performance (how fast?), security (how safe?), usability (how easy to use?), reliability (how often does it fail?), scalability (how does it behave under load?), and accessibility (can people with disabilities use it?). Both are essential, but non-functional requirements are often underspecified and need to be elicited explicitly from stakeholders.

17. What is use case testing?

Use case testing derives test scenarios from use cases — which describe sequences of interactions between users and the system to achieve a goal. For each use case, you test: the main success scenario (happy path), alternative flows (valid variations), exception flows (error conditions), and pre/post conditions. Use case testing is effective for system-level testing because it focuses on end-to-end user journeys rather than isolated features.

18. How do you prioritize test cases when time is limited?

Use a risk-based approach: focus on the areas with the highest probability of failure (recently changed code, complex logic, known problem areas) and the highest impact if they fail (critical user journeys, payment processing, authentication). Also consider: test cases that have caught bugs before, areas covered by recent requirements changes, and business-critical workflows. Explicitly document what you chose not to test and why — this is important for communicating risk to stakeholders.

19. What is alpha testing and beta testing?

Alpha testing is conducted by the internal team (developers, QA, and sometimes selected users) at the developer's site before the product is released to external users. Beta testing is conducted by a select group of external users in a real-world environment before the general release. Alpha testing catches major issues in a controlled setting; beta testing validates the product with real users and real usage patterns that the development team may not have anticipated.

20. What is UAT and who performs it?

User Acceptance Testing is the final phase of testing where actual business users (or their representatives) validate that the system meets their needs and is ready for production use. It's conducted in an environment that closely mirrors production. UAT is not about finding bugs (that should have happened earlier) — it's about confirming that the software fulfills the business requirements and that users can accomplish their goals. QA engineers often support UAT by preparing test data, environments, and documentation, but the actual testing is done by business stakeholders.

21. How do you test a login page?

Comprehensive login testing includes: valid credentials (happy path), invalid username, invalid password, empty username, empty password, both fields empty, SQL injection in username and password fields, XSS in both fields, very long strings (boundary values), special characters in password, case sensitivity check for username and password, "remember me" functionality, session behavior after login, redirect after login, account lockout after N failed attempts, password reset link validity and expiry, multi-factor authentication if applicable, and logout behavior.

22. What is negative testing?

Negative testing verifies that the system handles invalid inputs and unexpected user behavior gracefully — it doesn't crash, expose sensitive data, or allow unauthorized actions. Examples: entering letters in a numeric field, submitting a form without required fields, providing an expired credit card, uploading a file of the wrong type, entering SQL injection strings. Negative testing is as important as positive testing because users will make mistakes, and malicious users will deliberately try to break things.

23. What is the difference between black box and white box testing?

Black box testing treats the system as a black box — you test based on requirements and expected behavior without knowledge of the internal code structure. All functional testing techniques (equivalence partitioning, BVA, decision tables) are black box. White box testing involves knowledge of the code — you design tests based on the internal structure to ensure specific code paths, branches, and conditions are covered. Grey box testing combines both: testers have partial knowledge of the internals (like database schemas or APIs) to inform their test design.

24. What is ad hoc testing?

Ad hoc testing is unstructured, informal testing without a test plan, test cases, or documentation. Testers just use the application however they want, relying on intuition and experience. It can find bugs that formal testing misses, but results are hard to reproduce and coverage is unpredictable. It's most useful as a complement to structured testing, not a replacement. Exploratory testing is the structured, disciplined version of what ad hoc testing attempts informally.

25. What is the purpose of test exit criteria?

Exit criteria define the conditions that must be met before testing is considered complete for a given phase or release. Without exit criteria, testing can go on indefinitely or be cut short without a clear basis. Common exit criteria: pass rate above a threshold (e.g., 95% of test cases pass), no open critical or high-severity defects, all requirements have test coverage, performance targets met. Exit criteria should be agreed upon by the testing team and stakeholders before testing begins — not defined retroactively when someone wants to release.

26. What is risk-based testing?

Risk-based testing prioritizes testing effort based on the probability and impact of potential failures. You identify the riskiest areas (new code, frequently changed code, complex integrations, high-business-impact features) and allocate more testing time there. It's explicit acknowledgment that you can't test everything equally and must make informed decisions about where to focus. A risk register documents identified risks, their probability, impact, and the mitigation (test cases assigned to them).

27. What is the difference between retesting and regression testing?

Retesting is the process of re-executing a specific test that previously failed, after the defect it exposed has been fixed — verifying that the specific defect is resolved. Regression testing is the broader process of running a set of tests to verify that the fix (and any other recent changes) haven't broken existing functionality elsewhere in the system. Retesting is targeted; regression testing is a safety net.

28. What is a test harness?

A test harness is a collection of software and test data configured to test a software component under different conditions while monitoring behavior and output. It typically includes a test runner, stubs (replacements for dependent components that aren't available), drivers (components that invoke the code under test), and test data. Harnesses are particularly important in unit and integration testing where you're testing components in isolation from the full system.

29. How do you handle a situation where requirements are incomplete or unclear?

First, document what's unclear and what assumptions you're making — don't silently fill in gaps. Schedule a clarification session with the product owner or business analyst. If the clarification takes time, write tests against your documented assumptions and flag them as assumption-dependent. Use this as an opportunity to push for more specific requirements — ask "what happens when a user does X?" to surface scenarios that were overlooked. Ambiguous requirements are the leading cause of late-stage defects and rework.

30. What is the difference between load testing, stress testing, and soak testing?

Load testing verifies the system behaves correctly under expected user loads. Stress testing pushes the system beyond normal capacity to identify the breaking point and failure mode. Soak testing (endurance testing) runs the system at normal load for an extended period (hours, days) to detect memory leaks, resource exhaustion, and degradation over time. Each reveals different types of non-functional issues, and all three are necessary for a robust performance testing program.

31. What is test coverage and how do you measure it in manual testing?

In manual testing, coverage is typically measured as the percentage of requirements or user stories that have at least one associated test case (requirements coverage), or the percentage of test cases executed (execution coverage). Unlike code coverage tools, manual test coverage requires a traceability matrix. It's important to track not just "test exists" but "test was executed in this build" — a test case that was never run provides no coverage.

32. How would you test an e-commerce checkout flow?

Test scenarios include: complete purchase with valid credit card, purchase with expired card, purchase with insufficient balance, applying a valid discount code, applying an invalid/expired discount code, changing quantity in cart before checkout, removing items from cart, purchasing as a guest vs. registered user, shipping address validation (valid, invalid, international), calculating taxes for different regions, order confirmation email content, order history update, and inventory decrement after purchase. Also test edge cases: concurrent purchases of the last item in stock, very large order totals, and session timeout mid-checkout.

33. What documentation do you produce as a manual tester?

Typical deliverables: test plan, test cases (or test scenarios for exploratory testing), test execution reports (which tests ran, pass/fail, build number), defect reports, test summary report (coverage achieved, defects found by severity, open issues at release), and test sign-off documentation. In agile teams, documentation is lighter — testers maintain a test scenario list, link test cases to user stories, and provide a brief completion summary at the end of each sprint.

34. How do you test for usability?

Usability testing evaluates how easy and intuitive the application is for real users. Techniques include: task-based usability testing (observe users completing specific tasks and note where they struggle), heuristic evaluation (evaluate the UI against established usability principles like Nielsen's 10 heuristics), cognitive walkthroughs (simulate how a new user would approach the interface), and collecting qualitative feedback. Usability issues don't appear in functional test results — they require a different testing mindset that focuses on user experience, not just correctness.

35. Where does manual testing fit in a world with strong test automation?

Manual testing remains essential for: exploratory testing (finding unexpected behavior), usability and UX evaluation, one-time test scenarios that don't justify automation effort, accessibility testing (screen readers, keyboard navigation), and testing unstable areas of the UI where automation would be too brittle. The manual tester's role evolves toward higher-value activities — designing exploratory charters, evaluating the test strategy, performing risk analysis, and collaborating with SDETs on what to automate. Teams that try to automate everything find that some of the most important bugs are the ones only a human thinker would find.

Strong manual testing skills remain foundational even as the industry automates more. Understanding the principles of test design, risk-based prioritization, and clear defect communication will serve you throughout your QA career — regardless of how much automation your team adopts.