Manual Testing Interview Questions

What is manual testing?

Manual testing is the process of evaluating software by executing test activities without relying on automated scripts for the execution. A tester reviews requirements, prepares test conditions, performs user actions, compares actual results with expected results, and reports defects. Manual testing is particularly useful for exploratory testing, usability assessment, visual checks, and rapidly changing features.

What is QA in manual testing?

Quality assurance, or QA, is the broader process of preventing quality problems by improving the methods used to develop and test software. Manual testing is one activity within quality assurance. QA can include process definition, requirement reviews, risk analysis, test planning, audits, metrics, defect prevention, and continuous improvement.

What is the difference between quality assurance, quality control, and testing?

• Quality assurance: Process-oriented activities intended to prevent defects.
• Quality control: Product-oriented activities used to identify whether a product meets defined quality expectations.
• Testing: A quality-control activity that evaluates software and reveals failures, risks, and information about product quality.

What types of testing can be performed manually?

Manual execution can be used for functional, integration, system, acceptance, regression, smoke, sanity, compatibility, accessibility, localization, exploratory, and usability testing. Some performance and security checks may also involve manual investigation, although specialized tools are normally required for repeatable load, vulnerability, and code-level analysis.

What are the main levels of software testing?

• Component or unit testing: Evaluates individual components in isolation. Developers commonly perform it with code-based tests.
• Integration testing: Evaluates interfaces and data flow between components or systems.
• System testing: Evaluates the complete integrated system against specified requirements.
• Acceptance testing: Determines whether the solution satisfies acceptance criteria and business needs.

What is the difference between verification and validation?

Verification evaluates work products such as requirements, designs, and code to determine whether they meet specified conditions. It is often summarized as, “Are we building the product right?” Validation evaluates whether the implemented product satisfies its intended use and stakeholder needs: “Are we building the right product?” Reviews are an example of verification, while executing the application is an example of dynamic validation.

What is the Software Testing Life Cycle?

The Software Testing Life Cycle, or STLC, is a sequence of testing activities. A typical cycle includes requirement analysis, test planning, test analysis and design, test environment and data preparation, test execution, defect reporting and retesting, regression testing, and test closure. The activities may overlap or repeat in Agile projects rather than occurring as a single linear sequence.

What is a test scenario, and how does it differ from a test case?

A test scenario is a high-level statement describing what should be evaluated, such as “Verify that a registered customer can reset a forgotten password.” A test case gives the detailed preconditions, data, steps, and expected results needed to perform a specific check. One scenario can require several test cases covering successful, unsuccessful, boundary, security, and recovery paths.

What information should a manual test case contain?

• A unique test case ID and meaningful title
• Requirement, user story, or risk reference
• Preconditions and required test environment
• Test data and numbered execution steps
• Clear expected result for each relevant action
• Actual result, status, evidence, and defect reference after execution

The exact fields depend on the team’s process. A useful test case should be repeatable, understandable, and traceable to a requirement or risk.

What is a test plan?

A test plan defines how testing will be organized for a project or release. It normally identifies the scope, objectives, risks, test approach, environments, responsibilities, estimates, schedule, deliverables, tools, entry criteria, exit criteria, reporting method, and activities that are excluded. The plan may be a formal document or a shorter living plan, depending on the project.

What are entry and exit criteria in testing?

Entry criteria are conditions that should be satisfied before a test activity begins, such as an available build, approved requirements, prepared data, and a stable environment. Exit criteria are conditions used to decide when that activity can finish, such as completion of planned tests, acceptable requirement coverage, and resolution or formal acceptance of critical defects.

How do you prioritize manual test cases when time is limited?

Use risk-based prioritization. Execute tests for safety, security, revenue, legal obligations, and core user journeys first. Then consider features with high usage, recent or complex changes, integrations, historical defect concentrations, and functions that block other tests. Record the untested scope and explain the remaining risk to stakeholders rather than presenting partial execution as complete coverage.

What is a requirements traceability matrix?

A requirements traceability matrix maps requirements to test conditions or test cases. It helps reveal requirements with no corresponding tests, tests with no clear requirement, and the execution or defect status associated with each requirement. Traceability supports coverage analysis, but the number of mapped cases alone does not prove that testing is sufficient.

What is equivalence partitioning?

Equivalence partitioning divides input or output data into groups that are expected to be processed in the same way. The tester selects representative values from valid and invalid partitions instead of checking every possible value. For an age field accepting 18 through 60, the partitions could be below 18, from 18 through 60, and above 60.

What is boundary value analysis?

Boundary value analysis tests values at and around the edges of an ordered range because defects frequently occur at these transitions. If a field accepts values from 18 through 60, useful test values include 17, 18, 19, 59, 60, and 61. The exact selections should reflect whether each boundary is inclusive and whether robust invalid-value testing is required.

What is decision table testing?

Decision table testing represents combinations of conditions and the resulting actions as rules in a table. It is useful when business behavior depends on several inputs. For example, a discount may depend on membership status, order value, and coupon validity. The table helps identify missing, conflicting, and redundant rules before test cases are created.

What is state transition testing?

State transition testing checks how a system moves between states after events. It also checks invalid transitions and event sequences. A common example is an account that moves from active to temporarily locked after a defined number of failed login attempts and returns to active after successful recovery or the configured lock period.

What is exploratory testing?

Exploratory testing combines learning, test design, and execution. The tester works toward a defined mission or charter, observes the product, adapts tests based on findings, and records evidence and risks. It is not simply random clicking. Session notes, time boxes, coverage outlines, and debriefs make exploratory work reviewable.

How is ad-hoc testing different from exploratory testing?

Ad-hoc testing is informal and may have little planning or documentation. Exploratory testing is also adaptive, but it is generally guided by an objective, risks, a charter, and recorded observations. Both can reveal unexpected defects, but structured exploratory testing provides clearer accountability and coverage information.

What is the difference between smoke testing and sanity testing?

Smoke testing is a broad, shallow check of critical functions used to determine whether a build is stable enough for further testing. Sanity testing is a narrower check of a particular change or affected area, often performed after a small fix or update. Terminology varies between organizations, so an interview answer should explain how the terms were used on the candidate’s project.

What is regression testing, and how do you select a regression suite?

Regression testing checks whether a change has adversely affected existing behavior. Select tests according to change impact, business risk, dependencies, frequently used workflows, integrations, previous defect areas, and critical end-to-end paths. A regression suite should be reviewed regularly so obsolete cases are removed and new risks are represented.

What is retesting, and how is it different from regression testing?

Retesting executes the previously failed steps to confirm that a particular defect has been corrected. Regression testing checks related and existing functions for unintended effects of the change. A tester commonly retests the reported defect first and then runs an appropriate regression selection.

What is User Acceptance Testing?

User Acceptance Testing, or UAT, evaluates whether the system supports agreed business processes and acceptance criteria. It is normally performed by business representatives, customers, or intended users with support from the project team. UAT is not a substitute for system testing; it provides evidence for the business acceptance decision.

What should a useful defect report contain?

• A concise title describing the failure
• Build, environment, browser, device, or configuration details
• Preconditions, test data, and reproducible steps
• Expected result and actual result
• Severity, supporting logs, screenshots, or video
• Frequency, reproducibility, and relevant requirement or test references

The report should describe observed facts and avoid assumptions about the code-level cause unless evidence is available.

What is the difference between defect severity and priority?

Severity describes the technical or user impact of a defect. Priority describes how soon the organization wants it addressed. A crash in a rarely used internal function can be high severity but scheduled at a lower priority. A spelling error on a high-visibility release page can have low functional severity but high business priority.

What stages are included in a defect life cycle?

A common workflow is New, Triaged, Assigned, In Progress, Fixed, Ready for Retest, Retested, and Closed. Other possible outcomes include Duplicate, Rejected, Deferred, Cannot Reproduce, and Reopened. Status names and permitted transitions vary by team, so candidates should describe the workflow they actually followed.

What do you do when a developer says a reported defect is not reproducible?

Confirm the build and environment, repeat the exact steps with the same data, and check account state, permissions, network conditions, time zone, caches, and feature flags. Attach logs, timestamps, database references where permitted, screenshots, or a short recording. If it remains intermittent, document the observed frequency and pair with the developer to reproduce it rather than repeatedly reopening it without new evidence.

How do you perform root cause analysis for recurring defects?

Collect evidence, reproduce the failure, identify when and where it entered the process, and examine contributing factors. Techniques such as the Five Whys, cause-and-effect diagrams, change history, and defect clustering can help. Root cause analysis should lead to corrective and preventive actions, such as improving a requirement, review, design rule, test, monitoring check, or deployment control—not merely naming the person who introduced the defect.

How would you test a login page manually?

Start with the stated authentication rules and risks. Test valid and invalid credentials, blank fields, length and character boundaries, case behavior, locked and inactive users, repeated failures, password masking, keyboard navigation, error messages, session creation, logout, browser navigation, timeout, multiple tabs, and supported devices. Also check that sensitive values are not exposed in URLs, page content, or ordinary logs. Coordinate specialized security testing when deeper authentication assessment is required.

How would you test an e-commerce checkout flow?

Cover product and inventory state, quantities, prices, taxes, shipping, discounts, addresses, guest and registered users, supported payment outcomes, retries, duplicate submission, cancellation, timeout, confirmation, email or notification records, order history, and stock updates. Include interrupted networks and refresh or back-button behavior. Reconcile the amount shown at each step and verify that a failed payment does not create an incorrectly paid order.

How do you test when requirements are incomplete or unclear?

List the ambiguity and its impact, ask focused questions, review related stories and existing behavior, and discuss examples with the product owner, analyst, developer, or domain expert. Document assumptions and obtain agreement before treating them as expected behavior. Meanwhile, test confirmed requirements and use exploratory testing to identify risks, without silently converting personal assumptions into pass-or-fail criteria.

What would you do if a critical defect were found shortly before release?

Verify and document the defect promptly, assess affected users and workflows, identify workarounds, and communicate the evidence to the release decision-makers. Support impact analysis and test the proposed fix plus an appropriate regression scope. QA supplies risk information and a recommendation; the authorized stakeholders make the release decision according to the organization’s governance.

How do you investigate an intermittent or flaky manual test result?

First determine whether the variation comes from the product, test data, environment, timing, external service, or unclear procedure. Capture timestamps, request and response identifiers, logs, build information, network conditions, and the exact sequence. Repeat under controlled conditions, vary one factor at a time, and report the observed rate. Do not repeatedly rerun the test until it passes and then discard the earlier failures.

How do you report testing status to stakeholders?

Report scope completed, scope remaining, blocked tests, significant defects, affected requirements, environment issues, and current product risks. Use trends and concise evidence rather than only pass percentages. A useful status report distinguishes between “not tested,” “blocked,” “failed,” and “passed,” and states any assumptions behind the release recommendation.

What is test coverage in manual testing?

Test coverage describes the extent to which selected test conditions address requirements, risks, features, platforms, data combinations, or user journeys. Requirement coverage can be calculated as the percentage of in-scope requirements associated with executed tests, but that figure does not measure test quality by itself. Coverage should be interpreted with defect results, risk, test depth, and untested areas.

Which manual testing metrics are useful?

Useful metrics may include planned versus executed tests, pass, fail, blocked, and not-run counts; requirement or risk coverage; defect distribution by severity and area; defect age; reopen rate; and escaped defects. Metrics should support a decision or reveal a trend. Counting test cases or defects without context can reward unhelpful behavior and should not be treated as a direct measure of tester productivity.

Why is the test environment important in manual testing?

The environment determines the software version, configuration, integrations, operating system, browser, device, network, accounts, and data used during execution. Differences from the intended environment can hide defects or create false failures. Testers should record relevant configuration, control changes, monitor environment health, and identify where production-like behavior cannot be reproduced.

How should test data be managed?

Prepare data for valid, invalid, boundary, missing, duplicate, expired, and role-specific conditions. Make the setup repeatable, identify ownership, and reset or isolate data when tests can interfere with each other. Use generated or appropriately masked data instead of copying sensitive production information without authorization. Follow the organization’s privacy, access, retention, and disposal requirements.

How should a fresher prepare for a manual testing interview?

Learn testing terminology, STLC activities, test case structure, defect reporting, test levels, and common test design techniques. Practise testing familiar features such as login, search, forms, shopping carts, and file uploads. If you lack project experience, clearly identify a practice project and explain your reasoning instead of presenting it as employment experience.

What should an experienced tester include in interview answers?

Explain the project context, the risk or problem, your specific actions, the evidence you collected, how you collaborated, and the result. Interviewers generally need to understand your judgment and contribution, not only a textbook definition or a list of team activities.

Should a manual tester know SQL and API testing?

The requirement depends on the role. Basic SQL can help validate stored data, and API testing knowledge can help isolate service behavior before the user interface is available. Candidates should follow the job description and be honest about their level of hands-on experience.

Can all manual testing be replaced by automation?

No. Automation is useful for repeatable checks, large data combinations, and frequent regression execution, but it does not remove the need for human investigation, risk assessment, usability evaluation, and exploratory learning. Teams normally choose a combination based on risk, repetition, stability, cost, and the information needed.

How should you answer an unfamiliar manual testing interview question?

State what you understand, identify any assumptions, and reason from the requirement and risk. Ask a clarifying question if the scenario lacks essential context. It is better to describe how you would investigate than to invent experience or present an uncertain definition as fact.