Manual Testing Interview Questions: Derive Test Cases, Check Boundaries, and Explain Coverage

A strong answer to manual testing interview questions connects a requirement to an observable result. “I would test valid and invalid inputs” is a start. A stronger answer identifies which inputs exercise different rules, which boundaries could expose mistakes, and what evidence would distinguish a defect from an unanswered product question.

This guide follows one original reservation feature from requirements through coverage and defect reporting. For the wider interview scope, including automation and flaky tests, use the PracHub QA and SDET interview guide. Here, the focus is deriving and defending a compact manual test set.

Evidence boundary: ISTQB supplies the testing terminology cited below. The reservation rules, test cases, defect example, and self-review criteria are original practice material. They are not an employer's question bank, scoring rubric, or reported interview format.

What should you clarify before writing test cases?

Start with a contract small enough to reason about. Our fictional meeting-room service has these requirements:

• A request contains an integer guest count from 1 through 5, inclusive.
• Only verified accounts may submit a reservation.
• With valid input, a verified account gets Confirmed when a room is available and Waitlisted otherwise.
• Invalid input or an unverified account produces a rejection and creates no reservation.
• A confirmed reservation can be cancelled. A waitlisted reservation can be cancelled or promoted to confirmed when capacity becomes available. Cancelled reservations cannot be reactivated.

Assume each test begins with an isolated account and room fixture. Payment, recurring bookings, time zones, notifications, and concurrent allocation are outside this exercise. Naming those exclusions tells the reviewer which risks your test set has not addressed.

Then ask about missing details. Does an integer string such as "3" count as valid input? What message should appear when both verification and guest count fail? Are cancellations idempotent? Those questions affect expected results. Write down the agreed answer instead of silently choosing one and later calling a different implementation defective.

For our examples, the service accepts an integer value; null, fractional values, and arbitrary text are invalid. Error-message precedence remains unspecified. We can test rejection and absence of a new reservation without inventing the exact message. That is a useful distinction between a stable acceptance criterion and an open UX decision.

How do equivalence partitions reduce a test set?

Official terminology: equivalence partitioning divides inputs into groups expected to receive the same treatment. Boundary value analysis focuses on edges of ordered partitions. Decision tables cover combinations of conditions, while state-transition testing covers behavior that depends on previous state. These techniques address different questions; none alone proves the whole feature correct. ISTQB Foundation Level syllabus.

For guest count, begin with three numeric partitions: integers below 1, integers from 1 to 5, and integers above 5. Representatives such as 0, 3, and 6 exercise those three outcomes. Add separate type-related cases for null, a fraction, and text because they may follow different parsing paths.

Keep the other conditions favorable while isolating this rule: use a verified account and available capacity. Otherwise, a request with six guests might be rejected because the account is unverified, leaving the guest-count defect undetected.

An interview explanation might be: “I will first isolate guest-count validation with a valid account and available room. Then I will combine the conditions in a decision table. That makes each failure easier to interpret.” The value is the reasoning behind the cases, not the number of rows you can generate.

One representative per partition is an efficient starting point, not a guarantee that every member behaves identically. A parser may mishandle large values or overflow before applying the business rule. Add such cases when the interface, implementation clues, or risk justify them; label that as additional coverage.

Which boundary values would you test, and why?

For the integer domain, the partition edges around the allowed interval are 0, 1, 5, and 6. A two-value boundary set is therefore 0, 1, 5, 6: values immediately on either side of each validity change.

If you apply a three-value approach to each of those boundary values, add the nearest integer on both sides and remove duplicates. The resulting set is −1, 0, 1, 2, 4, 5, 6, 7. The ISTQB boundary-analysis paper explains the boundary conventions. State your domain and convention; “test three numbers” does not identify what was covered.

This set can expose a mistaken <= 6 upper check, an exclusive lower check, or an off-by-one error. It does not cover null or text: those are not adjacent integers. It also does not test a decimal step of 0.1 because fractional guest counts are invalid by contract.

If the UI prevents typing six, test the supported service interface as well when that is within the interview task. A restricted dropdown does not establish server validation. Conversely, do not claim to have tested an API if you only inspected a browser screen. Describe the layer you actually exercised.

How do you turn the rules into a decision table?

Use three Boolean conditions: guest input valid, account verified, and room available. There are eight raw combinations. The following reduced table groups combinations whose outcome does not depend on every condition. A dash means “either value,” not “unknown.”

R1 represents four raw combinations; R2 represents two; R3 and R4 represent one each. Four representative tests cover the reduced rules, but executing four representatives is not the same as executing all eight raw combinations. Report the denominator you actually used.

For R1, choose six guests with an otherwise valid setup. For R2, use three guests, an unverified account, and available capacity. R3 and R4 differ only in availability. Each case should assert both the returned outcome and the resulting reservation state.

The combined invalid-input/unverified-account case deserves an extra check if there is risk around validation order. Expect rejection and no side effect. Do not assert a particular error string until the product owner specifies precedence. If the interviewer changes that requirement, update the expected result and show which cases become affected.

Why are state-transition cases different?

A decision table describes the outcome of a request under conditions. A state model describes what may happen to an existing reservation. Testing creation does not establish that cancellation or promotion behaves correctly.

For this exercise, the allowed transitions are Confirmed → Cancelled, Waitlisted → Cancelled, and Waitlisted → Confirmed. A compact sequence can create a waitlisted reservation, make capacity available, promote it, and then cancel it. Check the same reservation ID throughout; accidentally creating a replacement could look correct in the UI while violating the intended lifecycle.

Use a separate fixture to cancel directly from waitlisted. Finally, attempt reactivation from cancelled and assert rejection with the state still cancelled. That negative transition checks the explicit terminal-state rule.

Three allowed transitions exercised out of three listed is a meaningful coverage statement. It says nothing about unlisted transitions, event sequences, competing users, or simultaneous promotions. If capacity allocation under concurrency matters, add a separate risk and test design rather than burying it under “state coverage complete.”

What does a reproducible defect report look like?

Suppose the fictional implementation accepts six guests. Your report should let another person reproduce the mismatch without interpreting your intentions.

Title: Reservation accepts six guests although the maximum is five.

Setup: practice build reservation-demo-v1; verified account test-verified-01; room fixture room-A with capacity available; no existing reservation for this test. These are fictional fixture identifiers, not production user data.

Steps: open the reservation form, enter guest count 6, submit once, and inspect the response and reservation list. If the UI limits the input, record the authorized service-level request used instead of claiming the UI accepted it.

Expected: reject the request and create no reservation, according to the inclusive 1–5 rule. Actual in this hypothetical defect: response indicates confirmed and one reservation with guest count 6 exists. Attach the response, relevant screenshot, and request or correlation ID if available. Record the exact build and test data.

Impact: the service can confirm bookings outside the supported guest limit. Triage recommendation: discuss urgency with the feature owner based on exposure and capacity consequences. Do not assign a universal severity number; teams define their own scales.

Notice the distinction between expected and actual evidence. This article gives a worked report, not a claim that a real application was tested. In an interview, never present a predicted failure as an observed one. Say “I would check whether a record was created” until you actually have that observation.

How would you explain coverage under a deadline?

Use a small worksheet linking each rule to cases, evidence, and remaining uncertainty. “Covered” should mean something more specific than “mentioned in my plan.”

If time allows only a few checks, prioritize a normal confirmed booking, an upper-bound rejection with no side effect, unverified-account rejection, and waitlisting when full. Explain which high-risk rule each covers. This is our practice prioritization, not an employer-mandated order.

Do not announce “100% coverage” without a model and denominator. You can say, “I executed four of four reduced decision rules, but have not tested every condition combination or concurrency.” That statement helps a reviewer decide what confidence the evidence supports.

Practice question: Validate Unit-Test Coverage and Identify Missing Scenarios (Capital One · Data Scientist)

How should you respond when the requirement is unclear?

Suppose someone asks whether cancelling twice should return an error or a success response. The supplied requirements do not settle that question. Record it as a product decision, propose alternatives, and explain consequences for clients and retries. Do not file a defect solely because your preferred behavior differs from the implementation.

Now suppose the rule explicitly says cancelled reservations cannot be reactivated, but the application restores one to confirmed. That is a requirement mismatch. The same testing habit—checking an observed result against an agreed oracle—separates the two situations.

When an interviewer challenges a case, revisit the assumption before defending the test. Ask whether the contract changed or whether you misunderstood it. Then identify which expected results need revision. A test suite should preserve agreed behavior, not preserve your first interpretation at all costs.

Practice with questions that require visible reasoning

Use these PracHub questions to rehearse test design, layer selection, prioritization, and communication. They are related practice, not a confirmed set from one employer.

Choose one question and write one requirement, one discriminating test, one observable result, and one limitation. If your answer only lists test categories, return to the reservation exercise and add concrete data. If it contains dozens of cases with no rationale, group them by the rule or risk they address.

Before moving into automation, use the QA and SDET guide to connect this manual reasoning to the test layer and maintenance cost. Automating an ambiguous expected result makes the ambiguity run faster; it does not resolve it.

Sources and Further Reading

• ISTQB Certified Tester Foundation Level syllabus v4.0.1: test techniques, coverage, and defect reporting

• ISTQB: Boundary Value Analysis white paper

• ISTQB glossary: defect report