Top 40 Manual Software Testing Interview Questions and Answers For 2027

• By Devraj

• 19th October 2026

Preparing for a manual testing interview can feel overwhelming, but the right preparation makes all the difference. Interviewers want to see that you understand the fundamentals of the software testing life cycle, can write clear test cases, report defects effectively, and think like an end user.

At Skill Hives, we’ve put together this collection of manual software testing interview questions to help both freshers and experienced testers build confidence. From core concepts like test case design, bug life cycle, and types of testing to real-world scenario-based questions, this guide covers what employers actually ask, so you can walk into your interview ready to impress.

Testing Basics (1–8)

1. What is software testing, and why is it needed?

Answer: Software testing is the process of checking an application to find defects and verify that it works according to the requirements.

It is needed to:

• Find bugs before users encounter them.
• Check that features work correctly.
• Protect user data and improve security.
• Improve performance, reliability, and user experience.
• Reduce the cost of fixing problems after release.

Example: If a user enters the correct username and password but cannot log in, software testing helps identify this problem before the application reaches customers.

2. What is manual testing?

Answer: Manual testing is a type of software testing in which a tester checks an application manually without using automated test scripts to execute the tests.

The tester follows test cases, enters data, checks results, and reports defects.

Example: A tester opens an e-commerce website, adds a product to the cart, enters a delivery address, and checks whether the checkout process works correctly.

Manual testing is especially useful for exploratory testing, usability testing, and checking new features.

3. Manual vs. automation testing: When do you choose manual testing?

Answer: Manual testing involves a human executing test steps, while automation testing uses scripts and tools to execute predefined checks.

When should you choose manual testing? Choose manual testing when:

• A feature is new and requirements are changing.
• You need to evaluate the user experience.
• You are exploring unexpected user behavior.
• The test is performed only a few times.
• Visual or contextual judgment is important.

Interview tip: Manual and automation testing complement each other. A good testing strategy uses both where appropriate.

4. What is SDLC?

Answer: SDLC stands for Software Development Life Cycle. It is a structured process used to plan, develop, test, release, and maintain software.

The main phases are:

• Requirement gathering: Understand what users and the business need.
• Planning: Estimate time, cost, resources, and risks.
• Design: Create the system architecture and user interface.
• Development: Write the code.
• Testing: Identify defects and verify requirements.
• Deployment: Release the application to users.
• Maintenance: Fix defects and improve the application.

Example: When developing a shopping app, the team first defines its features, designs the screens, builds the application, tests purchases, releases it, and maintains it after launch.

5. What is STLC, and what are its phases?

Answer: STLC stands for Software Testing Life Cycle. It describes the activities performed by a testing team to ensure software quality.

Its common phases are:

• Requirement analysis: Identify testable requirements.
• Test planning: Decide the scope, resources, schedule, and testing approach.
• Test case development: Prepare test cases and test data.
• Test environment setup: Configure the required hardware, software, and tools.
• Test execution: Run test cases and record results.
• Defect reporting and tracking: Report bugs and verify fixes.
• Test closure: Summarize results, lessons learned, and remaining risks.

Some organizations treat defect tracking as an activity across multiple phases rather than a separate phase.

6. What is the difference between verification and validation?

Answer: Verification checks whether the software is being developed according to specifications. Validation checks whether the final product meets user needs.

Example: Reviewing a login design against documented requirements is verification. Testing whether users can successfully log in with valid credentials is validation.

7. What is the difference between QA, QC, and testing?

Answer: Quality Assurance (QA), Quality Control (QC), and testing are related, but they have different purposes.

• QA: Focuses on improving processes to prevent defects.
• QC: Focuses on checking whether the product meets quality standards.
• Testing: Examines software behavior to identify defects and verify expected results.

Example: Creating a standard development process is QA. Reviewing a completed feature for quality is QC. Entering invalid login credentials to check the error message is testing.

Testing is an important QC activity, while QA is broader and focuses on the processes that support quality.

8. What are the seven principles of software testing?

Answer: The seven commonly recognized principles of software testing are:

• Testing shows the presence of defects: Testing can reveal bugs but cannot prove that software is completely bug-free.
• Exhaustive testing is impossible: Testing every possible input and condition is usually impractical.
• Early testing saves time and cost: Finding defects early generally makes them cheaper to fix.
• Defects cluster together: A small number of modules often contain a large proportion of defects.
• Pesticide paradox: Repeating the same tests may stop finding new defects, so tests need to evolve.
• Testing is context-dependent: Different applications require different testing approaches.
• Absence-of-errors fallacy: Software can be technically correct but still fail to meet user needs.

Example: A banking application needs strong security and transaction testing, while a simple informational website may focus more on content, navigation, and compatibility.

Want to build real software testing skills?

Ask Skill Hives about practical testing training, with hands-on practice and mentor guidance.

Testing Types (9–20)

9. What are the testing levels: unit, integration, system, and acceptance?

Answer: Testing levels represent different stages at which software components and the complete application are checked.

Unit tests are often written by developers. QA teams commonly perform integration and system testing, while acceptance testing may involve business stakeholders or end users.

10. What is the difference between black-box, white-box, and grey-box testing?

Answer: These approaches differ in how much knowledge the tester has about the application’s internal implementation.

• Black-box testing: Tests inputs and outputs without needing to know the internal code.
• White-box testing: Tests internal code, logic, branches, and execution paths.
• Grey-box testing: Tests the application with partial knowledge of its internal design or architecture.

Example: For a login feature:

• Black-box: Enter valid and invalid credentials.
• White-box: Check whether all relevant code branches execute correctly.
• Grey-box: Use knowledge of the authentication API and database structure to design tests.

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

Answer: Smoke testing checks whether the main features of a new build work well enough for further testing. Sanity testing checks whether a specific change or fix works as expected.

Example: After a new build, checking login, navigation, and checkout is smoke testing. After a discount calculation fix, checking discount calculations and related cases is sanity testing.

The terms may overlap in real-world team workflows.

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

Answer: Retesting verifies that a previously reported defect has been fixed. Regression testing checks whether a code change has caused problems in existing functionality.

Example: A developer fixes a password-reset bug.

• Retesting: Verify that the password-reset link now works.
• Regression testing: Check that login, registration, and other related account features still work.

Retesting focuses on the known defect, while regression testing focuses on unintended side effects.

13. What is exploratory testing?

Answer: Exploratory testing is an approach in which testers learn about an application, design tests, and execute them while investigating its behavior.

Instead of following only predefined test cases, the tester uses observations and experience to decide what to test next.

Example: While testing a shopping cart, a tester changes product quantities, refreshes the page, removes items, signs out, and returns to see whether the cart behaves correctly.

Exploratory testing is useful for finding unexpected issues that scripted test cases may miss.

14. What is ad-hoc testing?

Answer: Ad-hoc testing is informal testing performed without detailed test cases or a predefined structured test plan. The tester uses experience and intuition to try to identify defects.

Example: A tester quickly enters unusual characters into a search box, clicks buttons repeatedly, or refreshes a page during checkout to look for unexpected behavior.

Difference from exploratory testing: Exploratory testing is more deliberate and often has a learning objective or testing charter. Ad-hoc testing is generally less structured.

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

Answer: Functional testing checks what the application does. Non-functional testing checks how well the application operates.

Both are necessary because an application can have correct features but still be slow, difficult to use, or insecure.

16. What is usability testing?

Answer: Usability testing evaluates how easily real or representative users can understand and use an application to complete their tasks.

It focuses on:

• Ease of navigation.
• Clarity of instructions and labels.
• Ease of completing tasks.
• Error messages and recovery.
• Overall user experience.

Example: Ask users to purchase a product on a website without assistance. Observe whether they can find a product, add it to the cart, and complete checkout without confusion.

Usability testing helps identify problems that may not appear in functional test cases.

17. What is compatibility testing?

Answer: Compatibility testing checks whether an application works correctly across different browsers, operating systems, devices, screen sizes, and network conditions.

For example, a mobile shopping website should be checked on:

• Chrome, Firefox, Safari, and Edge, where relevant.
• Android and iOS devices.
• Small and large screens.
• Budget Android phones with limited memory or processing power.
• Slow 4G or unstable network connections.

Example: A checkout button works on a new iPhone but is hidden behind the keyboard on an older Android phone. Compatibility testing can identify this issue.

Prioritize combinations based on the application’s target users and usage data.

18. What is the difference between load testing and stress testing?

Answer: Load testing measures application performance under expected or anticipated user traffic. Stress testing pushes the application beyond its normal operating limits to understand how it behaves under extreme conditions.

The numbers are illustrative. Actual targets should come from business requirements and performance objectives.

19. What is the difference between alpha and beta testing?

Answer: Alpha and beta testing are forms of acceptance-oriented testing performed at different stages before a broader release.

• Alpha testing: Usually takes place within the organization or in a controlled environment.
• Beta testing: Involves selected external users who try the product in more realistic conditions.

Example: A company tests a new mobile app internally during alpha testing. It then releases a limited version to selected customers for beta testing and collects feedback about crashes, usability, and device compatibility.

20. What is UAT (User Acceptance Testing)?

Answer: User Acceptance Testing (UAT) checks whether the application meets business requirements and is suitable for its intended users.

Business users, customers, or designated stakeholders usually perform UAT using realistic business scenarios.

Example: For an invoicing application, a finance team checks whether it can create invoices, calculate taxes, apply discounts, record payments, and generate reports according to business rules.
UAT helps stakeholders decide whether the software is ready for acceptance. Passing UAT does not automatically mean every possible defect has been eliminated.

Test Design and Documentation (21–27)

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

Answer: A test scenario describes what needs to be tested at a high level, while a test case explains the specific steps, inputs, and expected results used to test it.

Example: Testing a login page

• Test scenario: Verify that users can log in successfully.
• Test case: Enter a registered email address, enter the correct password, click the Login button, and verify that the user reaches the dashboard.

One scenario can have multiple test cases covering valid credentials, invalid passwords, empty fields, and locked accounts.

22. What does a good test case contain?

Answer: A good test case contains enough information for another tester to execute it and understand the expected result.

Common components include:

• Test case ID.
• Test case title or description.
• Requirement or user story reference.
• Preconditions.
• Test data.
• Step-by-step instructions.
• Expected result.
• Actual result.
• Pass/fail status.
• Environment and relevant notes.

Example: A login test case should specify the account details, the steps to log in, and the expected dashboard or error message.

A good test case should be clear, repeatable, specific, and easy to maintain.

23. What is Boundary Value Analysis?

Answer: Boundary Value Analysis (BVA) is a test design technique that focuses on values at the edges of an allowed input range because defects often occur near boundaries.

Example: Suppose an age field accepts values from 18 to 60, inclusive.

Instead of testing every possible age, the tester focuses on the lower and upper boundaries and nearby values.

24. What is Equivalence Partitioning?

Answer: Equivalence Partitioning divides input data into groups that are expected to behave similarly. The tester selects representative values from each group rather than testing every possible input.

Example: An age field accepts values from 18 to 60.

• Invalid group 1: Ages below 18.
• Valid group: Ages from 18 to 60.
• Invalid group 2: Ages above 60.

Representative test values might be 15, 30, and 65.

This technique reduces the number of test cases while providing meaningful coverage. Boundary Value Analysis can be used alongside it.

25. What is Decision Table Testing?

Answer: Decision Table Testing is a technique used to test business rules involving multiple conditions and their corresponding outcomes.

Example: A website provides free delivery when an order is worth at least ₹1,000 and the customer has a premium membership.

Each row represents a combination of conditions and the expected outcome.

Decision tables are especially useful for discount rules, payment eligibility, insurance calculations, and access permissions.

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

Answer: A Requirement Traceability Matrix is a document that maps requirements to their related test cases and test results. It helps confirm that requirements have been tested and identifies gaps in coverage.

Example:

An RTM helps testers track coverage, assess the impact of requirement changes, and identify requirements without tests.

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

Answer: A test strategy describes the overall approach to testing, while a test plan explains how testing will be organized and executed for a particular project, release, or testing phase.

Example: A strategy might require automated regression testing for critical workflows. The test plan identifies which workflows will be automated, who will execute them, and when testing will happen.

The exact distinction varies by organization; some teams combine these documents.

Defect Management (28–32)

28. What is the bug life cycle?

Answer: The bug life cycle is the sequence of states a defect passes through from identification to closure.

A typical workflow is:

• New — Tester reports the defect
• Assigned — Defect goes to a developer
• In Progress — Developer investigates and fixes it
• Fixed — A fix is available for verification
• Retest — Tester verifies the fix

• Pass → Closed
• Fail → Reopened

Other possible states include Rejected, Duplicate, Deferred, and Cannot Reproduce. The exact workflow depends on the team’s defect management process.

29. What is the difference between severity and priority?

Answer: Severity describes how seriously a defect affects the system. Priority describes how urgently the team should fix it.

Severity is usually assessed by QA or the technical team, while priority is determined with input from product owners, business stakeholders, and engineering.

30. Give an example of high severity with low priority.

Answer: Suppose an application has a serious defect in an old reporting feature that causes the application to crash when a specific report is generated.

If that feature is rarely used, is disabled for the current release, and has an accepted workaround, the team might assign it high severity but low priority for the current release.

The defect is technically serious, but it may not require an immediate fix compared with issues affecting active, critical business operations.

Important: High-severity defects must still be assessed carefully. A workaround or low usage alone does not make a security, safety, or data-integrity issue safe to defer.

31. What makes a good bug report?

Answer: A good bug report is clear, reproducible, and detailed enough for a developer to understand and investigate the issue.

It should contain:

• A clear, specific title.
• Steps to reproduce the problem.
• Expected result.
• Actual result.
• Environment, device, browser, and application version.
• Test data or relevant preconditions.
• Severity and priority, where applicable.
• Screenshots, screen recordings, logs, or error messages.

Example:

Title: Checkout fails after applying a valid discount code.

Steps:

• Log in to the application.
• Add an eligible product to the cart.
• Enter a valid discount code.
• Click Apply.

Expected result: The discount is applied and the total is updated.

Actual result: An error message appears, and the total remains unchanged.

Evidence: Attach a screenshot and relevant browser console or network logs.

Never include real passwords, payment credentials, or unnecessary personal information in a bug report.

32. What do you do if a developer says, “It’s not a bug”?

Answer: I would discuss the issue professionally and use the documented requirements and evidence to determine whether the behavior is incorrect.

My approach would be:

• Reproduce the issue and confirm the test environment.
• Review the relevant requirement, acceptance criteria, or design.
• Share the steps, expected result, actual result, and supporting evidence.
• Discuss the behavior with the developer and product owner if the requirement is unclear.
• Agree on the correct outcome and update the defect status accordingly.

Example: If a developer says a missing error message is expected, I would check the acceptance criteria. If the behavior is not specified, I would ask the product owner to clarify the requirement rather than insist on an unsupported assumption.

The goal is to deliver the correct product, not to prove someone wrong.

Preparing for a QA or testing role?

Skill Hives can help you practise real-world testing scenarios and prepare for interviews.

Scenario-Based Questions (33–38)

33. How would you test a login page?

Answer: I would test the login page using positive, negative, security, usability, and compatibility scenarios.

My test cases would include:

• Login with valid credentials.
• Login with an incorrect password.
• Enter an unregistered email address.
• Submit with both fields empty.
• Submit with only one field completed.
• Check email format validation.
• Check password masking and show/hide functionality.
• Verify forgot-password and account-lockout behavior.
• Check session handling, logout, and unauthorized access.
• Test SQL injection and other relevant input attacks.
• Check repeated login attempts and rate limiting.
• Verify responsive behavior across supported devices and browsers.

I would also verify that error messages do not unnecessarily reveal whether a particular account exists.

Interview tip: Explain the test scenarios, expected results, and risks rather than simply listing inputs.

34. How would you test a UPI payment, including a failed payment where the money is debited?

Answer: I would test the complete payment journey, including successful transactions, failed transactions, delayed responses, duplicate requests, and transaction reconciliation.

My test approach:

• Verify successful payments with valid UPI details.
• Test invalid UPI IDs and insufficient balance.
• Test user cancellation and authentication failures.
• Simulate network disconnection or timeout during payment.
• Check whether the order status and payment status remain consistent.
• Tap Pay repeatedly or retry after a timeout to verify that duplicate charges are prevented.
• Verify transaction IDs, timestamps, and payment history.
• Test refunds and reconciliation for failed or pending transactions.

If money is debited but the payment fails on the app:

• Record the transaction reference, time, amount, and available evidence using test or authorized account data.
• Check the payment gateway or bank status through authorized systems.
• Verify whether the transaction is pending, failed, or successful.
• Ensure the order is not incorrectly marked as paid or failed without confirmation.
• Check that retries do not create duplicate charges.
• Follow the documented reconciliation and refund process.
• Escalate the issue immediately to the payment and engineering teams if real users are affected.

I would not assume the money will be refunded instantly. The resolution depends on the bank, payment provider, transaction status, and applicable dispute or refund timelines.

35. How would you test an e-commerce checkout?

Answer: I would test the entire checkout process from adding a product to receiving an order confirmation.

Key scenarios include:

• Add, remove, and update products in the cart.
• Verify product prices, quantities, discounts, taxes, and shipping charges.
• Apply valid, invalid, expired, and ineligible coupon codes.
• Test guest checkout and registered-user checkout.
• Validate delivery addresses and serviceability.
• Test multiple payment methods and payment failures.
• Check inventory changes during checkout.
• Prevent duplicate orders when users retry or refresh.
• Verify order confirmation, email notifications, and order history.
• Test mobile responsiveness, accessibility, and page performance.
• Check security and protection of payment information.

Example: If a customer pays successfully but the confirmation page fails to load, I would verify that the order is recorded correctly and that refreshing or retrying does not create another order.

36. How would you test a mobile app on a weak network?

Answer: I would test the application under different network conditions to verify that it handles delays, interruptions, and reconnections without losing data or confusing users.

My approach would include:

• Test on slow 4G, high latency, and limited bandwidth.
• Switch between Wi-Fi and mobile data.
• Turn on airplane mode during an API request.
• Disconnect the network during a payment or file upload.
• Check loading indicators, timeouts, and error messages.
• Verify retry behavior and recovery after reconnection.
• Check whether offline data is stored and synchronized correctly.
• Confirm that repeated requests do not create duplicate transactions.
• Monitor app crashes, responsiveness, battery use, and data consumption.

Example: If a user submits an order and loses connectivity, the app should clearly communicate the transaction state and verify the order status before allowing a potentially duplicate submission.

37. You have one day and 500 test cases. What do you do?

Answer: I would prioritize risk and business impact instead of trying to execute all 500 test cases without considering their importance.

My approach would be:

• Identify critical user journeys, such as login, payments, checkout, and core business functions.
• Review recent code changes and areas with a history of defects.
• Prioritize test cases based on severity, likelihood, and business impact.
• Execute smoke tests to confirm that the build is testable.
• Run high-priority functional and regression tests.
• Use existing automation for reliable repetitive checks where available.
• Assign work across available testers while avoiding conflicts and duplicated effort.
• Track results, defects, blocked tests, and remaining coverage.
• Communicate the risks and untested areas to stakeholders before release.

For example, I might run the 100 most critical tests first if that is what the risk assessment identifies, rather than automatically selecting the first 100 cases.

Important: I would not claim complete testing if only part of the test suite had been executed. The release decision should account for the remaining risks.

38. You find a critical bug just before release. What now?

Answer: I would immediately communicate the defect and its impact to the QA lead, development team, and release decision-makers.

My next steps would be:

• Reproduce the defect and collect evidence.
• Assess its impact on users, security, data, payments, or business operations.
• Determine which features and user groups are affected.
• Recommend holding the release if the risk is unacceptable.
• Work with developers to identify a fix or safe workaround.
• Retest the fix and run relevant regression tests.
• Review the release risks and obtain approval from the authorized stakeholders.

Example: If a critical payment bug causes customers to be charged twice, I would recommend blocking the release until the issue is resolved or an explicitly approved mitigation makes the release acceptably safe.

The key is to protect users and make a risk-based release decision rather than ignore the defect because the deadline is close.

Experienced and 2027 Topics (39–40)

39. How do you handle unclear or changing requirements?

Answer: I handle unclear requirements by clarifying expectations early, documenting decisions, and updating the test coverage whenever requirements change.

My approach includes:

• Ask the product owner or business analyst specific questions.
• Identify missing rules, edge cases, dependencies, and acceptance criteria.
• Use examples and decision tables to clarify complex business logic.
• Document assumptions and get confirmation from relevant stakeholders.
• Link requirements to test scenarios and test cases.
• Assess the impact of each change on existing features and regression tests.
• Update test data, documentation, and automation where necessary.
• Communicate how changes affect testing time, scope, and release risk.

Example: If a requirement says that a discount applies to eligible customers but does not define eligibility, I would clarify whether eligibility depends on membership, order value, location, or product category before finalizing the test cases.

In Agile projects, I would work with the team continuously rather than wait until development is complete.

40. How is AI used in software testing, and will it replace manual testers?

Answer: AI is being used to support test case generation, test data creation, defect analysis, visual testing, log analysis, and maintenance of automated tests. It can reduce repetitive work, but its output still requires human review.

Common uses include:

• Test case generation: Suggesting test scenarios from requirements and user stories.
• Automation assistance: Helping generate or maintain test scripts.
• Defect analysis: Identifying patterns in logs and grouping similar failures.
• Test prioritization: Recommending tests based on code changes and historical defects.
• Visual testing: Detecting unexpected differences between user interfaces.
• Synthetic test data: Creating representative data while protecting sensitive information.
• Self-healing automation: Attempting to recover when application elements change, subject to validation.

Will AI replace manual testers?

AI is more likely to change the testing role than eliminate the need for human testers entirely. It can handle some repetitive activities, but testers still need to understand business requirements, evaluate risk, investigate unexpected behavior, judge usability, and make decisions about product quality.

AI-generated tests can also contain incorrect assumptions, miss important edge cases, or produce false positives and false negatives. Testers must validate the results.

How should testers prepare for 2027?

• Strengthen software testing fundamentals.
• Learn API testing and SQL basics.
• Understand automation tools such as Playwright, Selenium, or Appium.
• Build skills in performance testing and security fundamentals.
• Learn how to use AI tools responsibly for test design and analysis.
• Develop analytical thinking, communication, and debugging skills.

Example: An AI tool might generate login test cases from a requirement. A skilled tester reviews them, identifies missing account-lockout and session-security scenarios, executes the tests, and evaluates the actual risk.

The strongest testers will combine technical skills, domain knowledge, critical thinking, and effective use of AI.

Final Interview Preparation Tips

• Understand the concept instead of memorizing every answer word for word.
• Support your answers with real or realistic examples.
• For scenario questions, explain your approach, the expected result, and how you would report failures.
• Be honest about your experience with testing tools and automation.
• For experienced roles, prepare examples involving defect prioritization, release decisions, changing requirements, and collaboration with developers.

FAQs: Manual Testing Interview Questions

1. What are the most commonly asked manual testing interview questions?

Common questions cover software testing basics, SDLC, STLC, test cases, bug life cycles, severity vs. priority, regression testing, and real-world testing scenarios.

2. Is manual testing easy for freshers to learn?

Yes, manual testing is a good starting point for freshers. Learning testing fundamentals, test case writing, defect reporting, and practical application testing can help beginners prepare for QA roles.

3. What is the difference between manual testing and automation testing?

Manual testing involves a tester checking software features manually, while automation testing uses scripts and tools to execute tests. Manual testing is useful for exploratory testing, whereas automation is effective for repetitive tests.

4. How can I prepare for a manual testing interview?

Learn software testing concepts, SDLC and STLC, testing types, test case design techniques, and bug reporting. Practice real-world scenarios such as testing a login page, payment system, and e-commerce checkout.

5. Can I get a software testing job without coding skills?

Yes, many entry-level manual testing roles do not require advanced coding skills. However, knowledge of SQL, API testing, and basic programming can improve your job opportunities and help you progress toward automation testing.

Ready to start your QA career?

Join Skill Hives to learn software testing step by step, with practical guidance and interview preparation.