Manual Testing Interview Questions and Answers (1970)

Manual testing is the process of executing test cases by a human tester without using automation tools — the tester interacts with the application, observes behavior, and reports defects. It is essential for exploratory, usability, ad-hoc, and UAT scenarios where human judgment is irreplaceable.

Human intuition uncovers UX and visual bugs automation misses; low setup cost for short-lived features; flexible when requirements shift daily; ideal for exploratory and usability testing; and no scripting expertise required.

Slower and non-repeatable at scale, prone to human error, expensive for regression across releases, hard to run in parallel, and difficult to measure precise performance metrics.

Manual is human-driven — flexible, exploratory, subjective. Automation is script-driven — fast, repeatable, objective. Manual is best for new features and UX; automation is best for regression, load, and data-driven checks. Modern teams use both.

Domain knowledge, analytical thinking, attention to detail, strong written communication (bug reports), test-design mastery (BVA, EP, decision tables), SQL basics, API testing basics (Postman), and familiarity with Jira, TestRail, or Zephyr.

QA is process-oriented and preventive (audits, reviews, standards, methodology). QC is product-oriented and corrective (inspection, testing, defect detection). QA improves the process; QC verifies the product.

Verification — are we building the product right? Static, done via reviews and walkthroughs. Validation — are we building the right product? Dynamic, done via test execution and UAT.

Test strategy is a high-level, project-agnostic document (org-wide policy). Test plan is project-specific (scope, schedule, resources, risks). Test case is the lowest level — steps, inputs, expected result for one scenario.

A good test case has: unique ID, clear title, precondition, atomic steps, single expected result, traceability to a requirement, priority, and no dependency on other tests. Rule of thumb: another tester should reproduce it exactly from your steps alone.

BVA tests at the edges of input ranges — min, min-1, min+1, max, max-1, max+1. For a text field 5–15 chars: test 4, 5, 6, 14, 15, 16 characters. Bugs cluster at boundaries where developers use wrong operators (< vs ≤).

EP divides inputs into partitions where behavior is expected to be identical, then tests one value per partition. For age 18–60: one from <18 (invalid), one from 18–60 (valid), one from >60 (invalid) — three tests instead of dozens.

A decision table lists all combinations of conditions and their expected actions. For a loan-approval rule (age, income, credit score), each row becomes a test case. Guarantees complete logical coverage and exposes missing rules.

Models the system as states and events. For a login screen: Logged-Out → Logged-In (correct password), Logged-Out → Locked (3 failed attempts). Tests cover valid transitions, invalid transitions, and state boundaries.

Pairwise testing covers all pairs of input combinations instead of every combination (which explodes combinatorially). Tools like PICT or AllPairs.exe generate the minimum set. Common when you have 5+ parameters with 3+ values each.

Positive testing checks the system does what it should with valid inputs (happy path). Negative testing checks the system gracefully handles invalid inputs (letters in a number field, expired token, malformed JSON) without crashing or exposing data.

Exploratory testing is simultaneous learning, test design, and execution — the tester uses charters, heuristics, and domain knowledge to probe the system. Best for new features, incomplete specs, complex workflows, and time-boxed risk assessments. Managed via Session-Based Test Management (SBTM).

Standard flow: New → Assigned → Open → In Progress → Fixed → Retest → Verified → Closed. Alternate states: Rejected, Deferred, Duplicate, Not-Reproducible, Reopened. Each transition is logged in Jira for audit and metrics.

Severity = business impact (Critical/High/Medium/Low). Priority = urgency to fix (P1/P2/P3/P4). A misspelled company name on the homepage is low severity but high priority; a crash on a rarely used feature is high severity but low priority.

Title, environment (browser, OS, build, device), preconditions, exact reproduction steps, actual result, expected result, severity, priority, screenshots/screen recording, console + network logs, reproducibility %, and a link to the failing test case.

Defect leakage = defects escaped to a later stage (e.g., found in prod that QA missed). Formula: Leaked defects ÷ Total defects × 100. Target < 5%. Track by root cause (missing test, environment gap, unclear requirement) and feed back into test-design.

Defect density = number of defects ÷ size of the module (KLOC, function points, or story points). Used to compare module quality and prioritize deeper testing on high-density modules.

Re-verify with the exact steps in a clean environment, capture video + logs, and share back. If disagreement continues, escalate with the requirement/specification reference and the business impact. If the spec is ambiguous, request a three-way call with the PO to lock behavior before closing.

Four levels: Unit (developers, individual functions), Integration (interactions between modules), System (end-to-end product against requirements), Acceptance (business stakeholders / users). Each level has entry/exit criteria and different owners.

Integration testing verifies interactions between modules. Approaches: Big Bang (all at once), Top-Down (stubs replace lower modules), Bottom-Up (drivers replace upper modules), Sandwich (both directions), Incremental (module-by-module).

Smoke is a shallow, wide check on a new build — do the core flows work at all? Runs before regression. Sanity is a narrow, deep check on a specific area after a small fix. Smoke is done by QA; sanity is often done by devs and QA together.

Regression testing re-runs existing test cases after any code change to confirm nothing that used to work is now broken. Primary automation candidate — grows in size every release. Managed via a curated regression suite plus risk-based prioritization.

Retesting re-executes the same failed test against a new build after the developer claims to have fixed the bug. Confirms the specific bug is fixed. Complements regression — retesting is bug-specific; regression is broader.

User Acceptance Testing is the final validation performed by end users or business stakeholders against real-world scenarios. Two flavors: Alpha (in-house users, controlled) and Beta (external users, limited release).

Compatibility testing verifies the application behaves correctly across browsers (Chrome, Safari, Firefox, Edge), OSes (Windows, macOS, iOS, Android), screen resolutions, and network conditions. Runs on BrowserStack, Sauce Labs, or LambdaTest.

Accessibility testing verifies the application is usable by people with disabilities per WCAG 2.1/2.2 (perceivable, operable, understandable, robust). Tools: axe DevTools, WAVE, Lighthouse. Manual checks with screen readers (NVDA, JAWS, VoiceOver) are irreplaceable.

An RTM maps each requirement to test cases, defects, and business objectives — proves 100% coverage, exposes untested requirements, and simplifies impact analysis when a requirement changes. Usually a spreadsheet or Zephyr/Xray column.

Test execution %: executed ÷ planned. Pass %: passed ÷ executed. Defect leakage %: prod defects ÷ total × 100. Defect density, mean time to detect, mean time to repair, automation coverage, and requirements coverage.

Combine multiple criteria: all planned test cases executed, exit criteria met (e.g., zero P1 open), risk-based coverage complete, defect-arrival rate flattens, and deadline reached with stakeholder sign-off. Never stop on a single metric alone.

Test Closure formally ends the testing phase. The Test Closure Report contains: summary of executed vs planned, defect statistics by severity/priority, root-cause analysis of leakage, lessons learned, and recommendations for the next release.

Risk-based testing prioritizes test effort on features with the highest combined impact × probability of failure. Business-critical flows (payment, login) get exhaustive coverage; low-risk features get sampled. Managed via a risk matrix updated per release.

Defect triage is a recurring meeting (usually daily during a release) where QA, dev leads, and PO review new defects, agree on severity/priority, assign owners, and decide fix-in-release vs defer. Prevents backlog explosion.

Positive: valid credentials, remember-me, password reveal. Negative: invalid password, blank fields, SQL injection, XSS in username, expired session, account locked after 3 attempts. Non-functional: response time < 2s, HTTPS, no credentials in URL, no password in local storage, session cookie HttpOnly + Secure, WCAG accessibility, tab navigation, screen-reader labels, mobile responsiveness.

Positive: valid card + PIN + amount within balance + within daily limit. Negative: wrong PIN (3 attempts → block), expired card, insufficient balance, exceed daily limit, cash-out of ATM, network drop mid-transaction (rollback), duplicate transaction, currency mismatch. Non-functional: response time, receipt printing, transaction logging, compliance with banking regulations.

Add single item, add multiple quantities, add out-of-stock item, add to cart from search/wishlist/PDP, cart persistence after logout/login, cart across devices, price updates when discount applied, tax calculation, currency conversion, cart limit (99 items), max cart value, and empty cart edge case.

Structure the answer as STAR: Situation (production issue found in staging), Task (isolate root cause), Action (used browser DevTools + backend logs + DB query to narrow to a race condition in the payment webhook), Result (patched before release, added regression test + monitoring alert). Interviewers score on process, not the bug itself.

Stay factual — share reproduction video, logs, environment, and the requirement or spec. If the requirement is ambiguous, get the PO in a call to lock behavior. Never escalate emotionally; escalate procedurally when specs are missing.

Reach out to the PO/BA in writing, refer to any related user story, competitor product, or industry standard. Write assumptions in the test plan, get sign-off, and log clarifications in a shared doc. Never guess silently — undocumented assumptions cause leakage.