Manual Testing – Interview Questions & Answers

Manual testing interviews usually test two things at the same time: whether you know the definitions and whether you can explain them in a practical project context. A candidate may memorize many terms, but interviewers often look for clarity, confidence, and real understanding. The goal is not to give long textbook answers for every question. The goal is to explain each concept accurately, connect it with project work, and show that you understand how testing is performed in real software delivery.

This guide presents important manual testing interview questions with expanded, interview-ready answers. Each answer starts with the core idea and then adds the practical explanation that helps in real interviews. The topics cover testing fundamentals, SDLC and STLC, test documentation, defects, test levels, test types, test design techniques, release readiness, UAT, production testing, and sign-off. These are the areas that most manual testing interviews return to again and again because they represent the foundation of a tester’s daily work.

While preparing, avoid answering only with one-line definitions. A one-line answer may be correct, but it may not show experience. For example, saying that regression testing ensures new changes do not break existing functionality is correct. A better answer also explains when regression is performed, how test cases are selected, and why it is important before release. Interviewers appreciate answers that are concise but not shallow.

1. What is Software Testing?

Software testing is the process of evaluating a software application to verify that it meets requirements, works as expected, and does not contain unacceptable defects. It helps teams understand the quality of the product before it reaches users. Testing is not only about finding bugs; it is also about providing confidence, reducing risk, validating business workflows, and helping stakeholders make release decisions.

In a real project, software testing includes understanding requirements, identifying test scenarios, preparing test cases, creating test data, executing tests, logging defects, retesting fixes, performing regression testing, and reporting test results. A strong interview answer should mention that testing improves quality by identifying gaps between expected and actual behavior. It does not prove that software is defect-free, but it provides evidence about product readiness.

2. What is the difference between Verification and Validation?

Verification checks whether the team is building the product right, while validation checks whether the team is building the right product. Verification is mostly a static activity because it can happen without executing the software. It includes reviews, walkthroughs, inspections, requirement reviews, design reviews, and test case reviews. The purpose is to find mistakes early in documents, designs, or plans.

Validation is a dynamic activity because it requires executing the software and observing behavior. Functional testing, system testing, regression testing, UAT, and end-to-end testing are examples of validation. A practical example is password reset. Verification checks whether the requirement and design clearly describe password reset behavior. Validation checks whether the user actually receives the reset link, can set a new password, and can log in successfully. Both are necessary for quality.

3. What is SDLC?

SDLC, or Software Development Life Cycle, is the structured process followed to build and maintain software. It defines phases such as requirement analysis, planning, design, development, testing, deployment, and maintenance. SDLC helps teams organize work, manage scope, reduce risk, and deliver software in a controlled way.

In interviews, it is useful to explain that testing is not isolated from SDLC. Testers participate from the requirement phase by reviewing requirements and identifying testable conditions. During design and development, testers prepare test scenarios, test cases, and test data. During testing, they execute and report. During deployment and maintenance, they support release validation and defect analysis. Understanding SDLC shows that a tester understands the full delivery process, not just test execution.

4. What is STLC?

STLC, or Software Testing Life Cycle, defines the structured phases followed specifically for testing activities. Common STLC phases include requirement analysis, test planning, test case design, test environment setup, test execution, defect reporting, retesting, regression testing, and test closure. STLC helps testing teams work systematically instead of testing randomly.

A strong answer should explain that STLC improves coverage, traceability, and control. In requirement analysis, testers understand what needs to be tested. In test planning, the scope, resources, schedule, and risks are defined. In test design, scenarios and test cases are prepared. In execution, actual results are compared with expected results. In closure, the team summarizes results, lessons learned, and remaining risks. STLC is the testing team’s roadmap.

5. What is a Test Plan?

A test plan is a document that defines how testing will be performed for a project or release. It describes the testing scope, objectives, approach, resources, schedule, test environment, tools, risks, entry criteria, exit criteria, deliverables, and responsibilities. It helps the team understand what will be tested, what will not be tested, who will test, and when testing will happen.

In practical terms, a test plan prevents confusion. Without a test plan, the team may not know which modules are in scope, which test types are needed, what environment will be used, or what conditions must be met before testing ends. In interviews, mention that a test plan is usually project-specific and is prepared by the test lead or QA lead with inputs from the team.

6. What is Test Strategy?

Test strategy is a high-level document that defines the overall testing approach, standards, methods, tools, and quality guidelines to be followed across projects or releases. While a test plan is usually specific to a project, a test strategy is broader and more stable. It may define test levels, test types, automation approach, defect management process, reporting standards, and risk-based testing approach.

A good interview answer should compare it with a test plan. Test strategy answers how testing is generally done in an organization or program. Test plan answers how testing will be done for a specific project. For example, the strategy may say that all critical flows must have regression coverage, while the test plan defines which regression cases will be executed for the current release.

7. What is a Test Scenario?

A test scenario is a high-level description of a functionality, workflow, or condition that needs to be tested. It focuses on what to test rather than exactly how to test. For example, “Verify successful login with valid credentials” is a test scenario. It identifies the business behavior that requires validation.

Test scenarios are useful during early test design because they help testers identify coverage areas before writing detailed test cases. A single scenario may lead to multiple test cases. For login, scenarios may include valid login, invalid login, locked account, forgotten password, empty fields, and session timeout. In interviews, explain that scenarios are broader, while test cases are detailed and executable.

8. What is a Test Case?

A test case is a detailed set of conditions, steps, test data, and expected results used to validate a specific requirement or behavior. A typical test case includes test case ID, title, preconditions, test steps, test data, expected result, actual result, status, and remarks. Test cases provide repeatability and traceability.

For example, for a login feature, a test case may specify opening the login page, entering a valid username and password, clicking the login button, and verifying that the dashboard is displayed. Test cases help testers execute consistently and help leads measure coverage and progress. A good test case should be clear, independent, reusable, and easy to understand.

9. What is Test Data?

Test data is the input used to execute test cases. It can include valid data, invalid data, boundary values, empty values, duplicate values, special characters, large data sets, user accounts, database records, files, dates, and configuration conditions. Good test data is essential because even a well-written test case can fail to validate properly if the data is poor.

In real projects, test data must match the scenario. For a loan approval workflow, testers may need applicants with different income levels, credit scores, ages, and employment statuses. For negative testing, they need invalid or restricted data. For boundary testing, they need minimum and maximum values. In interviews, mention that test data should be realistic, secure, reusable where possible, and aligned with requirements.

10. What is RTM?

RTM stands for Requirement Traceability Matrix. It maps requirements to test scenarios and test cases to ensure that every requirement has testing coverage. RTM helps identify missing test cases, track requirement coverage, and provide evidence that testing is aligned with scope.

A practical RTM may include requirement ID, requirement description, test case IDs, test execution status, defect IDs, and remarks. If a requirement has no test case, it indicates a coverage gap. If a defect is linked to a requirement, stakeholders can understand business impact. RTM is especially important in regulated or documentation-heavy projects where traceability is required.

11. What is a Defect?

A defect is a deviation between expected behavior and actual behavior. If the application does not work according to requirements, business rules, design, or user expectations, the issue can be reported as a defect. Defects may be functional, UI-related, performance-related, security-related, data-related, or integration-related.

For example, if a user enters valid credentials and the application rejects the login incorrectly, that is a defect. A good defect report should include title, steps to reproduce, expected result, actual result, environment, build version, severity, priority, screenshots, and supporting evidence. Clear defect reporting helps developers reproduce and fix issues faster.

12. What is the Defect Life Cycle?

The defect life cycle is the sequence of states a defect passes through from discovery to closure. Common states include New, Assigned, Open, Fixed, Retest, Closed, Reopened, Deferred, Rejected, and Duplicate. The exact workflow may differ by organization, but the idea is to track defect progress clearly.

A defect is first logged as New. It may be assigned to a developer and moved to Open. After fixing, it is marked Fixed or Ready for Retest. The tester retests it. If the fix works, the defect is Closed. If the issue still exists, it is Reopened. Defect life cycle helps teams manage defects systematically and maintain accountability.

13. What is Severity?

Severity indicates the impact of a defect on the application or business functionality. It answers the question: how serious is the defect? Severity is usually determined by the tester based on functional impact. Common severity levels are Critical, High, Medium, and Low.

A payment failure, application crash, data loss, or login failure may be critical or high severity because it blocks major functionality. A spelling mistake or minor alignment issue may be low severity. Severity focuses on impact, not scheduling. In interviews, emphasize that severity is about how badly the defect affects the system.

14. What is Priority?

Priority indicates how urgently a defect should be fixed. It answers the question: how soon should this issue be resolved? Priority is often decided by product owners, business stakeholders, project managers, or leads based on release timelines, business needs, customer impact, and urgency.

A defect may have high severity but lower priority if it affects a rarely used feature not planned for the current release. A low-severity defect may have high priority if it appears on the homepage or affects brand reputation. Priority is about fix order, while severity is about impact.

15. Difference between Severity and Priority?

Severity describes the impact of a defect on the system, while priority describes the urgency of fixing it. Severity is usually suggested by the tester because testers analyze functional impact. Priority is usually decided by business or project stakeholders because they understand release urgency and customer impact.

For example, if the application crashes during payment, severity and priority are both likely high. If there is a spelling mistake on a rarely used admin page, severity and priority may be low. If the company logo is wrong on the landing page, severity may be low from a functional point of view but priority may be high because it affects brand image. This example is commonly appreciated in interviews.

16. What is Smoke Testing?

Smoke testing is a quick and shallow validation performed on a new build to check whether the most critical functionality is working and whether the build is stable enough for detailed testing. It answers the question: is the build testable?

Smoke testing usually includes checks such as application launch, login, basic navigation, and critical workflow availability. If smoke testing fails, the build may be rejected and returned to development. Smoke testing saves time by preventing testers from running detailed test cases on a broken build.

17. What is Sanity Testing?

Sanity testing is a focused validation performed after a small change, bug fix, or minor enhancement to confirm that the changed functionality works as expected. It is narrow in scope and usually deeper than smoke testing in the affected area.

For example, if a defect is fixed in the password reset flow, sanity testing verifies that password reset now works and that closely related behavior is not obviously broken. Smoke testing checks overall build stability; sanity testing checks whether a specific change makes sense and is ready for further testing.

18. What is Regression Testing?

Regression testing ensures that new changes, fixes, or enhancements do not break existing functionality. Whenever code changes, there is a risk that previously working features may be affected. Regression testing protects system stability during change.

In real projects, regression test cases are selected based on impacted areas, critical business flows, defect history, integration points, and release risk. Regression can be partial or full depending on scope and time. A strong answer should mention that regression testing is broader than retesting and focuses on side effects.

19. What is Re-Testing?

Re-testing is the process of executing the same failed test case again to verify that a specific defect has been fixed. It is focused only on the reported issue. If the defect is resolved, the tester closes it. If the issue still exists, the tester reopens it.

Re-testing should use the same steps and similar data that originally exposed the defect. It confirms the fix. Regression testing, on the other hand, checks whether the fix caused side effects in other areas. In interviews, clearly separate these two concepts because they are often confused.

20. What is Exploratory Testing?

Exploratory testing is a testing approach where learning, test design, and test execution happen simultaneously. Testers do not depend only on predefined test cases. They explore the application using domain knowledge, experience, observation, and critical thinking.

Exploratory testing is useful for finding issues that scripted test cases may miss, especially in new, complex, or rapidly changing features. It is not random clicking. A skilled tester observes behavior, forms test ideas, follows clues, and records findings. Exploratory testing complements scripted testing and improves defect discovery.

21. What is Session-Based Testing?

Session-based testing is a structured form of exploratory testing. Testing is performed in time-boxed sessions guided by a charter. The charter defines the mission of the session, such as exploring checkout error handling or validating role-based access. After the session, the tester prepares notes or a session report.

Session-based testing provides a balance between creativity and accountability. It allows testers to explore freely within a focused scope while still producing evidence of what was tested and what was found. It is useful in Agile projects, complex workflows, and high-risk areas where detailed test cases may not cover every behavior.

22. What is Boundary Value Analysis?

Boundary Value Analysis, or BVA, is a test design technique that focuses on values at the edges of valid and invalid ranges. Defects often occur near boundaries because developers may make mistakes with greater-than, less-than, equal-to, minimum, or maximum conditions.

For example, if an age field accepts values from 18 to 60, boundary values include 17, 18, 19, 59, 60, and 61. Testing these values is more effective than testing many random values inside the range. BVA helps reduce test cases while increasing defect detection around limits.

23. What is Equivalence Partitioning?

Equivalence Partitioning, or EP, is a test design technique that divides input data into groups or partitions where the system is expected to behave similarly. Instead of testing every possible input, testers select representative values from each valid and invalid group.

For example, if a field accepts numbers from 1 to 100, valid values form one partition and values below 1 or above 100 form invalid partitions. Testing one or two values from each group gives useful coverage with fewer test cases. EP is commonly used with BVA for efficient test design.

24. What is Decision Table Testing?

Decision table testing is a technique used to test combinations of conditions and actions. It is useful when business rules depend on multiple inputs. A decision table lists conditions, possible combinations, and expected outcomes so testers can validate logic systematically.

For example, loan approval may depend on age, income, credit score, and employment status. Decision table testing helps ensure that all important combinations are checked. It is especially useful for business rules, pricing logic, eligibility checks, insurance rules, discounts, and approval workflows.

25. What is State Transition Testing?

State transition testing validates system behavior when an object or process moves from one state to another. It is useful when behavior depends on current state and triggered events. Examples include order status, ticket workflow, account status, login attempts, and defect life cycle.

For example, an order may move from Created to Paid, Shipped, Delivered, or Cancelled. Some transitions are valid and some are invalid. A delivered order may not be cancellable. State transition testing ensures that valid transitions work and invalid transitions are prevented.

26. What is Risk-Based Testing?

Risk-based testing is an approach where testing is prioritized based on business and technical risk. Since exhaustive testing is impossible, testers focus more effort on areas where failure would have the highest impact or highest probability.

High-risk areas may include payment, login, security, data migration, regulatory workflows, complex integrations, or modules with frequent defects. Risk-based testing helps teams use limited time wisely. A strong interview answer should mention impact, probability, priority, and business value.

27. What is UAT?

User Acceptance Testing, or UAT, is performed by business users or stakeholders to validate whether the system meets business needs and is ready for real use. QA testing may confirm technical correctness, but UAT confirms business readiness.

During UAT, users execute real business scenarios and confirm whether workflows, rules, data, and usability match operational expectations. QA may support UAT by preparing data, clarifying scenarios, and tracking defects, but the final acceptance decision belongs to business stakeholders.

28. What is Production Testing?

Production testing is limited and controlled validation performed in the live production environment after deployment. Its purpose is to confirm that critical functionality works correctly in the real environment. It is not full regression testing.

Production testing may include checking application availability, login, important business flows, configuration, integrations, and monitoring signals. It must use safe test data and approved checklists because production contains real users and real business data. The goal is deployment confidence, not broad coverage.

29. What is Test Coverage?

Test coverage measures how much of the application, requirements, scenarios, or code has been tested. In manual testing, coverage often refers to requirement coverage, scenario coverage, risk coverage, and test case coverage. It helps identify gaps in testing.

For example, if 100 requirements exist and test cases cover 90 of them, requirement coverage is 90 percent. High coverage improves confidence, but it does not guarantee defect-free software. Coverage should be meaningful, not just numerical. Critical business flows must be covered, not only easy scenarios.

30. What is Release Sign-Off?

Release sign-off is the formal approval confirming that testing is complete, known risks are reviewed, and the system is ready for production deployment. It is usually based on test summary reports, defect status, coverage, UAT results, exit criteria, and release readiness.

Release sign-off does not mean the application has no defects. It means stakeholders understand the quality status and accept the remaining risks. QA provides testing evidence, business stakeholders confirm acceptance, and release teams confirm deployment readiness. It is a governance checkpoint before production release.

How to Answer Manual Testing Questions in Interviews

When answering manual testing questions, start with a simple definition and then add a practical explanation. Interviewers want to see that you can apply the concept. For example, if asked about smoke testing, define it as a quick build stability check, then explain that it is performed after a new build is deployed and that a failed smoke test may block detailed testing.

Use examples wherever possible. Examples make your answer easier to understand and show real project thinking. For severity and priority, use the common logo or payment example. For BVA, use an age field or amount range. For decision table testing, use loan approval or discount rules. For UAT, explain business users validating real workflows.

Keep answers focused. A long answer is not always better. The best interview answers are clear, structured, and relevant. Explain the concept, mention when it is used, give a practical example, and if useful, compare it with a related concept. This approach works well for most manual testing interview questions.

Key Takeaway

Manual testing interviews are built around fundamentals, process understanding, defect handling, test design techniques, and release readiness. If you understand the difference between verification and validation, SDLC and STLC, test scenarios and test cases, severity and priority, smoke and sanity, retesting and regression, and UAT and production testing, you can answer most beginner and intermediate interview questions confidently.

The strongest candidates do not only memorize definitions. They explain concepts in a project context. They understand why testing is performed, how defects are managed, how coverage is measured, how risk is prioritized, and how release decisions are made. That practical understanding is what makes manual testing knowledge interview-ready.