Top 100 Manual Testing Interview Questions & Answers

Manual Testing is the process of testing the performance, quality, security, and other aspects of software before release. A QA tester analyses, plans, executes, and reports the performance of software under various test case scenarios — identifying potential risks, flaws, bugs, and glitches in the developmental phase so developers can fix issues before launch.

Manual testing offers human insights, creativity, and analytical abilities that automated tools lack. A human is required to analyse requirements and instruct automated tools on how to approach testing. After tests complete, human comprehension determines where software needs improvement. AI may write its code, but human intuition cannot be replaced for exploratory, usability, and ad-hoc testing.

Verification is a static analysis technique. Testers perform the test without involving code review — examples include reviewing, inspecting, or walking through documentation.

Validation is a dynamic technique where codes are involved, examined, tested, and validated. The tester checks whether there is any potential risk in the code itself.

Positive testing validates software with valid data input — the system should accept it and respond correctly. Negative testing validates with invalid data input — the system should reject it gracefully. For example: software that accepts only alphanumeric entries should give a positive response to alphanumeric input and a nullified response to special characters.

Boundary Value Analysis (BVA) belongs to the Black Box Testing method. It detects errors at the extreme limits of a set input domain — for example, testing values just above and below an age minimum of 18.

Equivalence partitioning is a black box technique where testers club data into classes or groups and input them into the software. It saves time and reduces the number of tests while achieving comprehensive coverage — instead of testing every possible value, you test one representative from each partition.

STLC (Software Testing Life Cycle) is an integral part of SDLC. It is a sequence of activities carried out one after the other to ensure software quality is not compromised. The team of QA testers decides which tests are to be performed and in what order.

The six main phases are:

• Requirement Analysis
• Planning Test Scenarios
• Developing Test Cases
• Setting up the Test Environment
• Executing the Tests
• Test Cycle Closure

Test Planning is the second phase of every STLC. The team of testers defines the objective, scope, strategy, etc. of the project. For example, a test plan for banking software includes testing security features, UI/UX, and load testing to determine functionality under pressure.

A Test Plan defines scope, approach, emphasis, and objective of a test. A Test Strategy is the set of guidelines that describes the design of the test and the steps to perform it. Strategy is high-level and organisation-wide; a test plan is project-specific.

Exploratory testing is where a tester uses experience and intuition to learn and discover bugs in software without help from any test script or cases. It is done to ensure the software is error-free after all other tests have been executed, and relies entirely on human analytical ability.

Smoke testing determines if the crucial parts of the software are working. Also known as confidence testing or build verification testing, it is performed between two test executions to confirm the build is stable enough for the next round of tests.

Sanity testing is a quick test of the codebase to verify it is a stable build. It is performed after changes have been made to the code — ensuring the new code is running properly without creating new bugs or glitches before deeper testing resumes.

In smoke testing, critical parts of software are tested to check readiness for the next test phase. In sanity testing, when a new feature is added, that feature is specifically tested to verify the whole software remains stable. Smoke is broader; sanity is narrower and change-triggered.

Regression testing is a re-run of tests previously executed on software. It includes functional and non-functional tests to ensure the software still performs as expected after code changes. The purpose is to confirm that new changes have not broken existing functionality.

Defect severity (also called Bug Severity) is the method of determining the impact of a defect or bug on the system's functionality that can affect end-user experiences. High severity means the system cannot function; low severity means cosmetic or minor issues that do not block usage.

A bug is an error detected at any given developmental stage of software. A defect is a mismatch between the expected outcome/response and the actual outcome/response of the software. All defects are bugs, but not all bugs become defects — some are acceptable deviations from the specification.

The Defect Life Cycle refers to all steps taken in the SDLC to fix a detected bug — from bug identification through resolution. It tracks a defect through states such as New, Assigned, Open, Fixed, Retest, Verified, and Closed to ensure nothing falls through the cracks.

Three core stages in manual testing defect management:

• Prioritise Defect — assess severity and business impact
• Resolve Defect — assign to developer, fix, and retest
• Report Resolution — document outcome and close the loop with stakeholders

Test coverage is the percentage of code tested and whether available test cases cover all lines of code. Four types:

• Statement Coverage — every executable statement executed at least once
• Decision Coverage — every decision branch evaluated to true and false
• Branch Coverage — every branch from each decision point executed
• Toggle Coverage — every feature flag combination tested

Risk-based testing is the process of developing a software strategy that prioritises the risk of failure in particular features or functions. High-risk areas get the most testing attention and earliest coverage — ensuring that the features most likely to fail or most critical to users are validated first.

Exploratory testing offers constant, fast feedback to developers without requiring pre-curated test cases — critical in agile where requirements evolve quickly. Because it is executed freely based on tester intuition, it surfaces issues that scripted tests would miss during rapid iteration cycles.

No. Automated testing cannot replace manual testing. Manual testing offers human insight, perspective, intuition, and creativity that automated testing lacks. Software is built for people — and only people can validate whether it truly meets their expectations in the nuanced, unpredictable ways real users interact with it.