120+ Manual Testing Interview Questions

Software testing plays a vital role in delivering reliable, secure, and user-friendly applications. Manual testing remains an important part of quality assurance because it helps testers evaluate application behavior, explore unexpected scenarios, and identify usability issues that automated checks may not detect easily.

Whether you are preparing for your first QA interview or have several years of software testing experience, understanding manual testing concepts is essential. Interviewers commonly ask about testing fundamentals, test case design, defect management, testing methodologies, Agile practices, and real-world testing scenarios.

In this guide, we cover 50+ manual testing interview questions and answers, from basic concepts to advanced topics, to help you prepare for software testing interviews.

01👉 Basic Manual Testing Interview Questions

1. What is software testing?

Software testing is the process of evaluating a software application to identify defects and verify whether it meets specified requirements. Testing helps assess the application's functionality, reliability, security, usability, and overall quality.

2. What is manual testing?

Manual testing is a software testing approach in which testers execute test cases or explore an application manually without relying on automated test scripts to perform the checks.

For example, a tester may manually enter valid and invalid login credentials to verify the application's login behavior.

Learn more: What Is Automation Testing?

3. Why is software testing important?

Software testing helps teams:

• Identify defects before software reaches users.
• Verify that requirements are implemented correctly.
• Improve application reliability and usability.
• Reduce the risk of production failures.
• Validate security and performance requirements through appropriate testing.
• Increase confidence in software releases.

Testing reduces risk, but it cannot guarantee that software is completely defect-free.

4. What is the difference between quality assurance and quality control?

Quality assurance (QA) focuses on improving the processes used to build and deliver software. Quality control (QC) focuses on evaluating the product to identify quality problems.

5. What is the difference between verification and validation?

Verification checks whether work products meet specified requirements and design expectations. Validation checks whether the software meets user needs and intended use.

A common way to remember the distinction is:

• Verification: Are we building the product right?
• Validation: Are we building the right product?

Verification can include reviews and inspections without executing the software. Validation commonly involves executing the application.

6. What is the difference between an error, a defect, and a failure?

• Error: A human mistake, such as misunderstanding a requirement or writing incorrect code.
• Defect: A flaw in a requirement, design, code, or another work product.
• Failure: An observable event in which the system does not behave as expected during execution.

For example, a developer may make a coding error that introduces a defect, which later causes the application to display an incorrect total.

7. What are the main categories of software testing?

Software testing can be classified in different ways.

By testing objective:

• Functional testing
• Non-functional testing

By access to internal implementation:

• Black-box testing
• White-box testing
• Grey-box testing

By execution approach:

• Manual testing
• Automated testing

These categories overlap. For example, regression testing can be performed manually or through automation.

8. What are the advantages of manual testing?

Manual testing is particularly useful for:

• Exploratory testing and investigating unexpected behavior.
• Evaluating usability and user experience.
• Testing new or frequently changing features.
• Checking visual presentation and interaction flows.
• Investigating defects that require human judgment.

Manual testing is not always cheaper or slower than automation. The appropriate approach depends on the project, test frequency, complexity, and maintenance cost.

9. What are the limitations of manual testing?

Common limitations include:

• Repetitive tests can consume considerable time.
• Results may vary between testers.
• Large regression suites can be difficult to execute frequently.
• Manual execution is not suitable for simulating thousands of concurrent users efficiently.
• Repeated checks may be affected by human error.

A combination of manual and automated testing is often the most effective approach.

10. Can automation testing replace manual testing?

No. Automation is useful for repeatable checks, regression testing, data-driven scenarios, and frequent executions. Manual testing remains valuable for exploratory testing, usability evaluation, and situations that require human judgment.

The two approaches complement each other.

02👉 Software Testing Life Cycle and Documentation

11. What is the Software Testing Life Cycle (STLC)?

The Software Testing Life Cycle is a structured sequence of testing activities performed to assess software quality.

Common STLC phases include:

1. Requirement analysis
2. Test planning
3. Test case design and development
4. Test environment setup
5. Test execution
6. Test cycle closure

The exact workflow may vary depending on the organization's development and testing methodology.

Read more: Software Testing Life Cycle.

12. What is the Software Development Life Cycle (SDLC)?

The Software Development Life Cycle is the process used to plan, design, develop, test, deploy, and maintain software.

Typical activities include requirements gathering, analysis, design, implementation, testing, deployment, and maintenance.

13. What is a test plan?

A test plan is a document that describes the scope, objectives, approach, resources, schedule, and responsibilities for testing.

It may also define test deliverables, risks, entry criteria, exit criteria, and the test environment.

14. What is a test scenario?

A test scenario describes a high-level functionality or situation that needs to be tested.

Example: Verify that a registered user can log in successfully.

A single scenario can be covered by multiple detailed test cases.

15. What is a test case?

A test case is a documented set of conditions, inputs, actions, and expected results used to verify a particular behavior or requirement.

A typical test case contains:

• Test case ID
• Title or description
• Preconditions
• Test data
• Test steps
• Expected result
• Actual result
• Execution status

16. What is the difference between a test scenario and a test case?

17. What is a testbed or test environment?

A test environment is the configured combination of hardware, software, network settings, services, and data used to test an application.

A testbed is often used to describe the configured setup in which testing takes place.

For example, a web application's test environment may include a staging server, supported browsers, a test database, and sample user accounts.

18. What is test data?

Test data is the information used to execute test cases and verify application behavior.

For a registration form, test data may include valid email addresses, invalid email formats, empty fields, duplicate accounts, and boundary-length inputs.

Good test data should cover valid, invalid, boundary, and business-specific scenarios.

19. What is a Requirement Traceability Matrix (RTM)?

An RTM maps requirements to corresponding test cases and, where applicable, defects and execution results.

It helps teams verify that requirements have appropriate test coverage and identify requirements that have not been tested.

20. What are entry and exit criteria?

Entry criteria are the conditions that should be met before a testing activity begins.

Examples include an available build, approved requirements, and a configured test environment.

Exit criteria define the conditions for completing a testing activity.

Examples include completing planned tests, reviewing critical defects, and achieving agreed coverage or pass-rate targets.

Exit criteria should be based on project risks and release requirements rather than a pass percentage alone.

03👉 Testing Types and Test Design Techniques

21. What is functional testing?

Functional testing verifies whether application features behave according to specified requirements.

Examples include login, registration, search, checkout, payment, and password reset testing.

22. What is non-functional testing?

Non-functional testing evaluates quality attributes such as performance, security, usability, accessibility, reliability, and compatibility.

For example, performance testing measures response times under defined workloads.

23. What is black-box testing?

Black-box testing evaluates an application's behavior without requiring knowledge of its internal implementation.

Testers provide inputs and compare the actual outputs with expected results.

Common techniques include equivalence partitioning, boundary value analysis, decision table testing, and state transition testing.

24. What is white-box testing?

White-box testing uses knowledge of the internal structure or implementation of software to design or evaluate tests.

It may involve statement coverage, branch coverage, condition coverage, and other structural testing techniques.

25. What is grey-box testing?

Grey-box testing combines external behavioral testing with partial knowledge of the application's internal design or architecture.

For example, a tester may validate a user-facing transaction while also checking relevant database records or API responses.

26. What is smoke testing?

Smoke testing is a broad, initial set of checks used to determine whether a build is stable enough for more detailed testing.

For example, a tester may verify that the application launches, users can log in, key pages load, and major workflows are accessible.

27. What is sanity testing?

Sanity testing is a focused set of checks performed to assess whether a specific change or fix appears to work correctly.

For example, after a login defect is fixed, a tester may verify login behavior and closely related functionality.

The precise use of smoke and sanity testing terminology can vary between teams.

28. What is regression testing?

Regression testing checks whether software changes have unintentionally affected existing functionality.

For example, after modifying the checkout page, a tester may verify cart calculations, discount application, payment processing, and order confirmation.

29. What is retesting?

Retesting means executing a test again to verify whether a previously reported defect has been fixed.

For example, if a password reset link previously expired too early, the tester repeats the relevant test after the fix.

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

31. What is exploratory testing?

Exploratory testing combines learning about an application, designing tests, and executing them. Testers use observations from one test to guide subsequent tests.

It is particularly useful when requirements are incomplete, or testers need to discover unexpected issues.

32. What is ad hoc testing?

Ad hoc testing is an informal testing approach without a detailed predefined test procedure.

Testers use their knowledge and intuition to explore the application and identify potential defects.

Exploratory testing is generally more deliberate because learning, test design, and findings guide the ongoing investigation.

33. What is the difference between positive and negative testing?

Positive testing checks whether the application behaves correctly with valid inputs.

Negative testing checks whether the application handles invalid inputs, unexpected actions, or error conditions appropriately.

For a login form, positive testing uses valid credentials, while negative testing may use an incorrect password, empty fields, or an invalid email format.

34. What is equivalence partitioning?

Equivalence partitioning divides input data into groups expected to produce similar behavior. Testers select representative values from each group.

For example, if an age field accepts values from 18 to 60:

• Valid partition: 18–60
• Invalid partition: Below 18
• Invalid partition: Above 60

Other invalid classes, such as letters or empty input, should also be considered if relevant to the field's requirements.

35. What is boundary value analysis?

Boundary value analysis focuses on values at and near the edges of an allowed range because defects frequently occur at boundaries.

For an age field that accepts values from 18 through 60, useful test values include:

• 17 — below the minimum
• 18 — minimum valid value
• 19 — just above the minimum
• 59 — just below the maximum
• 60 — maximum valid value
• 61 — above the maximum

36. What is decision table testing?

Decision table testing verifies application behavior for combinations of conditions and corresponding actions.

For example, an online store may apply a discount only when a customer is eligible and the minimum order amount is reached. A decision table helps test the relevant combinations systematically.

37. What is state transition testing?

State transition testing verifies how an application changes from one state to another in response to events.

For example, an account may move from active to locked after a specified number of unsuccessful login attempts.

Testers check valid transitions, invalid transitions, and the resulting system behavior.

38. What is the pesticide paradox in software testing?

The pesticide paradox describes the situation in which repeatedly running the same tests eventually becomes less effective at finding new defects.

To improve defect detection, testers should review and update test cases, introduce new scenarios, explore different inputs, and adapt tests when requirements or risks change.

04👉 Defect Management and Bug Reporting

39. What is a bug or defect?

A defect is a flaw in a software work product that may cause the application to behave differently from its specified or intended behavior.

The terms bug and defect are often used interchangeably in everyday QA work.

40. What is a defect life cycle?

The defect life cycle describes the states a defect passes through from identification to closure.

A common workflow is:

New → Assigned → In Progress → Fixed → Retest → Verified → Closed.

Other possible states include Reopened, Rejected, Duplicate, Deferred, and Cannot Reproduce. Actual states depend on the team's defect management process.

Read more: Defect Life Cycle in Software Testing.

41. What is a good bug report?

A good bug report provides enough clear, reproducible information for a developer to investigate the issue.

It typically includes:

• Defect ID and title
• Environment and build details
• Preconditions
• Steps to reproduce
• Expected result
• Actual result
• Severity and priority
• Screenshots, logs, or recordings when useful

Read more: How to Write a Bug Report

42. What is the difference between severity and priority?

Severity describes the impact of a defect on the application or users.

Priority indicates how urgently the team should address the defect.

For example, a spelling mistake on a prominent launch page may have low severity but high priority because of its business visibility.

43. What is defect triage?

Defect triage is the process of reviewing reported defects and deciding how to handle them.

The team may consider severity, priority, business impact, reproducibility, release timelines, affected users, and available resources.

44. What is defect leakage?

Defect leakage occurs when a defect is not detected during the intended testing activities and is discovered in a later stage, such as production.

For example, a payment calculation issue missed during pre-release testing may be discovered by a customer after deployment.

45. What is defect density?

Defect density measures the number of confirmed defects relative to a defined measure of software size or scope.

For example, a team might calculate defects per thousand lines of code or per functional unit. The metric is meaningful only when the measurement method and scope are clearly defined.

46. What is a blocker defect?

A blocker defect prevents a critical testing activity, workflow, or release from proceeding.

For example, if all test users are unable to access the application because authentication is unavailable, testing may be blocked.

The exact definition of blocker depends on the team's defect classification rules.

05👉 Advanced Software Testing Interview Questions

47. What is API testing?

API testing verifies that an application's Application Programming Interfaces behave as expected.

Testers may validate request parameters, response codes, response bodies, authentication, authorization, error handling, data integrity, and response times.

API testing is often useful for detecting issues in business logic and integrations without depending entirely on the user interface.

48. What is performance testing?

Performance testing evaluates how a system behaves under defined workloads.

It can assess response time, throughput, resource utilization, stability, and scalability.

Common types include load testing, stress testing, endurance testing, spike testing, and volume testing.

49. What is load testing?

Load testing measures system behavior under an expected or specified workload.

For example, an e-commerce application might be tested with 1,000 concurrent simulated users to evaluate response times and error rates. The appropriate workload depends on business requirements and expected traffic.

50. What is stress testing?

Stress testing evaluates how a system behaves beyond its expected operating limits or under unusually demanding conditions.

It helps identify capacity limits, failure modes, and recovery behavior.

51. What is usability testing?

Usability testing evaluates how easily and effectively users can complete tasks using an application.

It may examine navigation, clarity, consistency, error messages, and the effort required to complete important workflows.

52. What is accessibility testing?

Accessibility testing checks whether people with disabilities can use an application effectively.

It may include keyboard navigation, screen reader compatibility, focus visibility, color contrast, and appropriate labels for interactive elements.

53. What is compatibility testing?

Compatibility testing verifies that software behaves correctly across supported environments, such as browsers, operating systems, devices, screen sizes, and configurations.

For web applications, testers may validate the same workflow across Chrome, Firefox, Safari, and supported mobile browsers.

54. What is security testing?

Security testing evaluates whether an application protects its data, functionality, and resources against security risks.

It may include authentication and authorization checks, session management, input validation, access control, and vulnerability assessments.

55. What is concurrency testing?

Concurrency testing evaluates how an application behaves when multiple users or processes access shared resources or perform operations simultaneously.

For example, testers may check whether two users attempting to purchase the last available product cause an incorrect inventory count.

56. What is backend testing?

Backend testing evaluates server-side logic, database operations, integrations, and data processing.

For example, after placing an order through the UI, a tester may verify that the order record, payment status, and inventory updates are consistent.

57. What is pairwise testing?

Pairwise testing is a test design technique that selects combinations of input parameter values so that every pair of values across parameters appears in at least one test.

It helps reduce the number of test cases required when an application has many configuration combinations.

58. What is mutation testing?

Mutation testing evaluates the effectiveness of a test suite by making small, deliberate changes to the code and checking whether the tests detect those changes.

It is primarily used to assess the quality of tests, rather than directly to validate application features.

59. What is fuzz testing?

Fuzz testing supplies unexpected, malformed, or randomly generated inputs to software to identify crashes, incorrect behavior, or potential security weaknesses.

It is commonly used to evaluate input handling and robustness.

60. What is failover testing?

Failover testing verifies whether a system can switch to a backup component or service when the primary component fails.

For example, a team may simulate a server failure and verify that the application continues operating through a backup server with acceptable data integrity and recovery behavior.

61. What is configuration management in software testing?

Configuration management controls and tracks changes to software versions, test assets, configuration files, environments, and related artifacts.

It helps teams maintain consistency, identify the correct build, and reproduce test results.

62. How do you decide when to stop testing?

Testing is generally considered complete when agreed exit criteria are met, and the remaining risks are acceptable to the relevant stakeholders.

Factors may include:

• Completion of planned testing activities.
• Required requirements and risk coverage.
• Status of critical and high-priority defects.
• Results against defined quality objectives.
• Remaining time and resources.
• Business and release risk.

A high pass rate alone does not prove that an application is ready for release.

06👉 Agile and Scrum Interview Questions

63. What is Agile testing?

Agile testing is testing performed as part of an iterative development approach, with continuous collaboration between testers, developers, product owners, and other stakeholders.

Testing occurs throughout development rather than being limited to a single phase at the end.

64. What is Scrum?

Scrum is an Agile framework that helps teams develop and deliver value through iterative, incremental work.

It uses defined accountabilities, events, and artifacts to support transparency, inspection, and adaptation.

65. What are the main accountabilities in Scrum?

The Scrum framework defines three accountabilities:

• Product Owner: Accountable for maximizing product value and effective Product Backlog management.
• Scrum Master: Accountable for establishing Scrum and improving the team's effectiveness.
• Developers: Accountable for creating a usable increment during the Sprint.

Testers may be part of the Developers within a Scrum Team.

66. What is a daily Scrum meeting?

The Daily Scrum is a short event for Developers to inspect progress toward the Sprint Goal and adapt their plan.

QA team members can use team discussions to communicate testing progress, blockers, risks, and coordination needs.

67. What is the difference between Agile and Waterfall testing?

Actual project practices vary, and Waterfall projects can also include early and continuous testing activities.

68. What is Test-Driven Development (TDD)?

Test-Driven Development is a development practice in which a developer writes a test before implementing the corresponding functionality.

A common cycle is:

1. Write a test that fails.
2. Write the minimum code needed to pass.
3. Refactor the code while keeping the tests passing.

TDD is a development practice, not simply a manual testing technique.

07👉Scenario-Based Manual Testing Interview Questions

69. How would you test a login page?

I would begin by reviewing the requirements and then test:

• Login with valid credentials.
• Login with an incorrect password.
• Empty username and password fields.
• Invalid email formats, where applicable.
• Password masking and show/hide behavior.
• Forgot password and account recovery.
• Account lockout or rate limiting, where required.
• Session behavior and logout.
• Keyboard navigation and accessibility.
• Error messages and relevant security controls.

I would prioritize scenarios according to risk and business impact.

70. How would you test an application when requirements are unclear?

I would clarify the expected behavior with the product owner, business analyst, or relevant stakeholder.

Meanwhile, I would document assumptions, review existing workflows, explore the application, identify risks, and create provisional test scenarios. I would confirm the assumptions before treating them as final acceptance criteria.

71. What would you do if a developer could not reproduce your reported bug?

I would verify the issue again and provide clear reproduction steps, environment details, build information, test data, screenshots, recordings, or logs where available.

I would also check whether the issue depends on timing, user permissions, browser configuration, or specific data. If necessary, I would work with the developer to reproduce the issue collaboratively.

72. How would you test an e-commerce checkout page?

I would cover:

• Product and cart details.
• Quantity updates and item removal.
• Price calculations, discounts, taxes, and shipping.
• Address validation.
• Payment success, failure, cancellation, and retry.
• Duplicate order prevention.
• Order confirmation and order history.
• Inventory updates.
• Session handling and security.
• Responsive behavior and usability.

I would also test boundary conditions and integration failures.

73. What would you do if you found a critical defect just before release?

I would document the defect, confirm its impact, assess affected workflows, and immediately notify the responsible QA lead and release stakeholders.

I would provide evidence, identify potential workarounds if appropriate, and support risk assessment. The release decision should follow the organization's release process and the severity of the issue.

74. How would you prioritize testing when time is limited?

I would use a risk-based approach.

I would prioritize critical business workflows, security-sensitive operations, recently changed features, integrations, high-impact failure scenarios, and areas with a history of defects.

I would communicate any untested areas and residual risks clearly rather than assuming that the remaining functionality is safe.

75. How would you test a file upload feature?

I would verify:

• Supported file types and extensions.
• Minimum and maximum file sizes.
• Valid, invalid, and corrupted files.
• Empty file selection.
• Multiple-file uploads, if supported.
• Duplicate uploads.
• Upload progress and cancellation.
• Network interruptions and retries.
• Error messages and successful completion.
• Appropriate access controls and file handling security.

The exact scenarios should match the feature requirements.

76. How would you test a search feature?

I would test:

• Exact and partial matches.
• Case sensitivity and whitespace handling.
• Empty searches.
• No-result scenarios.
• Special characters and invalid input.
• Sorting, filtering, and pagination.
• Large result sets.
• Response time under expected conditions.
• Relevant keyboard and accessibility behavior.

I would also verify that results are accurate and respect user permissions.

8. Manual Testing Interview Preparation Tips

To prepare effectively for a QA interview, focus on understanding concepts and applying them to real software rather than memorizing definitions alone.

Practice writing test cases.s

Choose familiar features such as login, registration, checkout, search, and password reset. Write positive, negative, boundary, and exploratory scenarios.

Learn defect reporting

Practice writing bug titles, reproduction steps, expected results, actual results, severity, and priority. Clear defect reports demonstrate practical QA skills.

Understand the testing lifecycle.le

Review STLC, test planning, test design, execution, defect management, regression testing, and test closure.

Prepare scenario-based answers

Interviewers may ask how you would test a feature, handle unclear requirements, prioritize limited testing time, or investigate a difficult defect. Explain your reasoning step by step.

Understand manual and automated testing together.

Learn which tests are best suited to human exploration and which benefit from repeatable automation. Familiarity with API testing, regression testing, and CI/CD can also strengthen your understanding of modern QA workflows.

08Conclusion

Manual testing remains an important part of software quality assurance. It helps teams validate requirements, investigate unexpected behavior, assess usability, and identify defects that could affect users.

Preparing for manual testing interviews requires a strong understanding of testing fundamentals, test design techniques, defect management, the Software Testing Life Cycle, and real-world QA scenarios.

Use these questions to review key concepts, practice explaining your approach, and develop examples from your own testing experience. As you gain practical experience, focus on explaining not only what a testing technique is, but also when you would use it and why it matters.

Continue learning with QACraft:

• Software Testing Life Cycle
• What Is Automation Testing?
• How to Write a Bug Report
• Defect Life Cycle in Software Testing
• Test Automation Frameworks

If your team needs support improving software quality, test coverage, or release confidence, explore QACraft's software testing services to learn how a structured QA approach can help your project.