Your one-stop platform to prepare, practice and ace your interviews.
Loading your questions…
20 hand-picked Manual QA interview questions with detailed answers. Open the interactive version above to search, filter by difficulty, run code, bookmark questions and track your progress.
A test case is a documented set of steps, data, and expected results used to verify a specific behaviour.
A good test case is clear, reusable, and independent. It usually includes: ID, title, preconditions, steps, test data, expected result, and sometimes priority/severity.
Typical flow: New → Assigned → Open/In Progress → Fixed → Retest → Verified/Closed. Branches: Rejected (not a bug), Deferred (fix later), Reopened (fix failed), Duplicate.
Tools like Jira track status, owner, and history so triage stays organised.
Severity = how badly the defect impacts the system (technical impact). Priority = how soon it should be fixed (business urgency).
Example: a typo on the homepage can be low severity but high priority before a marketing launch. A crash in a rarely used admin screen can be high severity but low priority.
UAT is acceptance testing by business users/clients to confirm the system meets real-world needs and is ready for production.
System testing is usually done by QA against requirements in a test environment. UAT focuses on business workflows, real data scenarios, and sign-off — not every low-level validation.
Equivalence Partitioning (EP) groups inputs that should behave the same, then tests one value from each group (valid/invalid partitions).
Boundary Value Analysis (BVA) tests the edges of those groups — bugs often live at min/max limits (e.g. 0, 1, 100, 101 for a 1–100 range).
A good bug report lets someone reproduce and fix without guessing: clear title, environment/build, preconditions, steps, test data, actual vs expected result, severity/priority, evidence (screenshots/logs/API response), and optionally related story/module.
Title: Checkout total ignores 10% coupon CODE10 on QA
Env: QA v24.6.1, Chrome 126
Steps: ...
Actual: Total remains 100
Expected: Total becomes 90
Evidence: screenshot + network responseA test scenario is a high-level what-to-test statement ("Verify user can reset password"). A test case is the detailed how — steps, data, expected results for that scenario.
Scenario: User resets password
Cases: valid reset, expired link, mismatched confirm passwordDecision tables map combinations of conditions to actions/outcomes. Useful when business rules have multiple inputs (role + order status + payment state → allowed actions).
VIP=Y, Order=OPEN, Paid=Y → Allow cancel with refund
VIP=N, Order=SHIPPED, Paid=Y → Cancel blockedState transition testing validates that an entity moves between allowed states with valid events, and rejects invalid transitions. Example order states: CREATED → PAID → SHIPPED → DELIVERED; cannot jump CREATED → DELIVERED.
CREATED --pay--> PAID --ship--> SHIPPED
CREATED --ship--> ✘ rejectedFrom the main success path, alternate paths, and exceptions. Convert acceptance criteria into scenarios, then into cases with data. Include negative and boundary conditions the story implies.
Story: Cancel order within 1 hour
- Success within 60 min
- Reject after 61 min
- Unauthorized user cannot cancelIdentify data needed per scenario (users, orders, products), keep it reusable and unique where collisions matter, document setup/cleanup, and avoid depending on fragile production-like leftovers. Prefer dedicated QA accounts and factories/scripts for repeatable data.
qa.order.user+<timestamp>@test.com
seed order in CREATED status for cancel testsA blocker prevents major testing or a critical user journey (can’t login, can’t place order). You escalate immediately, pause dependent testing if needed, and treat it as release-stopping unless a formal waiver exists.
Ad-hoc is informal, unstructured testing without documented design. Exploratory is also unscripted but more disciplined — time-boxed charters, notes, and follow-up cases. Exploratory is preferred professionally.
Alpha is performed in-house (internal users/QA) before external release. Beta is performed by limited external real users in a production-like setting to gather feedback before full launch.
Track each case as Pass/Fail/Blocked/Not Run (and sometimes Skipped). Summarise by module/priority, link failures to defects, and report progress against exit criteria daily during release testing.
High priority: 40 Pass / 2 Fail / 1 Blocked / 7 Not RunTriage reviews new/open defects with QA, dev, and often product: confirm validity, set/adjust severity & priority, assign owners, target fix version, and decide defer/reject/duplicate. Goal is a clear, prioritised backlog.
Error guessing uses experience to invent likely failure cases that formal techniques may miss — double-submit, empty optional-but-used fields, copy-paste whitespace, timezone boundaries, concurrent edits.
Double-click Place Order → two orders?
Paste email with trailing space → login fails?Build Verification Testing (BVT) / build acceptance is a short smoke pack that decides if a new build is stable enough for deeper testing. If BVT fails, the build is rejected.
BVT: login, open dashboard, create order draft, logoutA closure report summarises scope tested, execution results, open defects (by severity), risks/waivers, environment/build, and recommendation (go/no-go). It is the evidence behind sign-off.