Test Design
Black-box test-design techniques — equivalence partitioning, boundary-value analysis, decision tables, test-case structure, and checklists.
13 questions
JuniorTheoryVery commonWhat is boundary-value analysis and why test boundaries specifically?
What is boundary-value analysis and why test boundaries specifically?
Boundary-value analysis tests the edges of each input range, since defects cluster at boundaries (off-by-one, wrong operator). For a range you check the minimum, maximum, and the values just inside and just outside each edge, not only the middle of the partition.
Common mistakes
- ✗Testing only the exact boundary, not the values just inside/outside
- ✗Skipping boundaries because equivalence classes were already covered
- ✗Confusing the boundary with the middle of a partition
Follow-up questions
- →For a range 1–100, which exact values would you test?
- →Why do off-by-one errors make boundaries defect-prone?
JuniorTheoryVery commonWhat is equivalence partitioning and why is it useful?
What is equivalence partitioning and why is it useful?
Equivalence partitioning splits input data into classes the system treats the same way, then tests one representative per class. It assumes any value in a class behaves like the others, so you cut the number of test cases while keeping coverage of valid and invalid groups.
Common mistakes
- ✗Forgetting to define invalid as well as valid classes
- ✗Confusing it with boundary-value analysis (edges)
- ✗Believing it guarantees finding every defect
Follow-up questions
- →How does equivalence partitioning relate to boundary-value analysis?
- →Give a valid and an invalid class for an age field 18–65.
JuniorTheoryVery commonWhat fields make up a good test case?
What fields make up a good test case?
A good test case has a unique ID, a clear title, preconditions, ordered steps, and an explicit expected result; often priority and test data too. It must be unambiguous, reproducible, and independent, so anyone can run it and get the same outcome without guessing intent.
Common mistakes
- ✗Omitting the explicit expected result
- ✗Writing steps that depend on another case's leftover state
- ✗Using vague steps that aren't reproducible
Follow-up questions
- →Why must a test case be independent of others?
- →What does the precondition field capture?
JuniorTheoryCommonWhat is the difference between a test scenario and a test case?
What is the difference between a test scenario and a test case?
A test scenario is a high-level, one-line statement of what to test — an end-to-end flow or feature. A test case is the detailed, step-by-step realization of a scenario: an ID, preconditions, ordered steps, test data, and an explicit expected result. One scenario usually expands into several test cases; the scenario says what, the case says exactly how.
Common mistakes
- ✗Swapping which one is high-level and which is detailed
- ✗Treating scenario and case as interchangeable synonyms
- ✗Expecting one case to expand into many scenarios rather than the reverse
Follow-up questions
- →How many test cases might one scenario expand into, and why?
- →Which artifact carries the explicit expected result?
MiddleDesignCommonYou are given an add-only calculator: it accepts two integers from -99 to +99, has a clickable "=" button, and an output field for the result (e.g. 4+5=9). Design the test cases. Explain how you would clarify requirements first, why you start with positive checks, how you cover boundaries and equivalence classes, the input and output field length limits, and which single check you would keep if only one could ship to production.
You are given an add-only calculator: it accepts two integers from -99 to +99, has a clickable "=" button, and an output field for the result (e.g. 4+5=9). Design the test cases. Explain how you would clarify requirements first, why you start with positive checks, how you cover boundaries and equivalence classes, the input and output field length limits, and which single check you would keep if only one could ship to production.
Clarify first (platform, allowed characters), then start positive: a valid addition like 4+5=9. Cover boundaries (-99, +99 and just outside -100, +100), equivalence classes (valid integers, invalid: fractions, letters, symbols), and the field limits — input fits 3 chars (sign + 2 digits), output fits 4 (sign + 3 digits). Test the output field separately. If only one check ships, keep the positive one — it proves the core function works.
Common mistakes
- ✗Starting with extreme negatives instead of a positive check
- ✗Ignoring the output field and the "=" button
- ✗Enumerating all values instead of using classes and boundaries
Follow-up questions
- →How many characters can the input and output fields each hold, and why?
- →Why is
X+0a weak check for an addition feature?
MiddleDesignCommonYou're given an e-commerce cart screen: a list of items with quantity and price, a promo-code field, an order total, and 'Remove' and 'Checkout' buttons. Describe your approach to a test checklist for this screen — what you would check, in what order, and how you would group the items.
You're given an e-commerce cart screen: a list of items with quantity and price, a promo-code field, an order total, and 'Remove' and 'Checkout' buttons. Describe your approach to a test checklist for this screen — what you would check, in what order, and how you would group the items.
Group checks by area: layout/content render, then functional flows (change quantity recalculates total, remove updates list, valid/invalid promo, checkout enabled only with items), then edge cases (empty cart, zero/max quantity, expired promo), then non-functional (responsive, errors). Each item is a short verifiable check, ordered from positive happy-path to negative and boundary.
Common mistakes
- ✗Covering only the happy path and skipping negative/boundary checks
- ✗Not grouping items by area, producing an unordered jumble
- ✗Writing items too coarse to verify (one check = one statement)
Follow-up questions
- →Which boundary cases apply to the quantity field?
- →How would you turn one checklist item into a full test case?
MiddleTheoryCommonWhat is a decision table and when is it better than equivalence classes?
What is a decision table and when is it better than equivalence classes?
A decision table maps combinations of input conditions to expected actions, one column per rule. It shines when outputs depend on several interacting conditions — unlike equivalence partitioning, which handles inputs independently — ensuring every meaningful combination of business rules gets a test case.
Common mistakes
- ✗Using a decision table for a single independent input
- ✗Forgetting to collapse impossible or don't-care combinations
- ✗Confusing rules (columns) with individual conditions (rows)
Follow-up questions
- →How many rules does a table with 3 boolean conditions have at most?
- →When would you collapse columns with a don't-care value?
MiddleTheoryCommonHow do you correctly verify that an email address is valid?
How do you correctly verify that an email address is valid?
Format and regex checks are necessary but never sufficient — the RFC for valid addresses is huge, and a syntactically valid address may still be undeliverable. The only definitive verification is to send a confirmation message and require the user to act on it (click a link or enter a code). Syntax proves shape; the confirmation step proves the mailbox actually exists and is owned.
Common mistakes
- ✗Believing a regex alone proves validity and deliverability
- ✗Conflating valid syntax with a real, owned mailbox
- ✗Skipping the confirmation step as redundant
Follow-up questions
- →Why can a syntactically valid address still be undeliverable?
- →What does the confirmation step prove that a regex cannot?
MiddleDesignCommonA discount spec reads: under 18 → 15%, from 19 to 35 → 15%, from 35 → 20%. Before writing any tests, what would you do? Identify the gaps and ambiguities in this specification, name the specific ages that fall through or are double-covered, and list the clarifying questions you would ask. Explain why the correct first action here is to question the requirement rather than to start designing test cases.
A discount spec reads: under 18 → 15%, from 19 to 35 → 15%, from 35 → 20%. Before writing any tests, what would you do? Identify the gaps and ambiguities in this specification, name the specific ages that fall through or are double-covered, and list the clarifying questions you would ask. Explain why the correct first action here is to question the requirement rather than to start designing test cases.
Question the spec first, do not test it. Age 18 falls through a gap — "under 18" excludes 18 and "from 19" excludes it too, so 18 is uncovered. Age 35 is double-covered, appearing in both the 19–35 rule and the "from 35" rule. Ask: are the boundaries inclusive or exclusive, is there a max age, is age counted by day or exact time, and is the date local or UTC? A requirement you cannot resolve is untestable.
Common mistakes
- ✗Designing tests before resolving the spec gaps
- ✗Missing the uncovered age 18 and double-covered age 35
- ✗Assuming boundaries are inclusive without asking
Follow-up questions
- →Which exact age falls through the gap, and why?
- →What clarifying question best resolves the overlap at 35?
MiddleDesignCommonA web server answers 200 to a GET whose query string is exactly 8 digits, and 503 to anything else. Design the test cases for this API. Cover the positive and negative inputs you would derive with boundary-value analysis and equivalence partitioning, what you would do if a response differs from the two specified codes, and what kind of test 1000 simultaneous clients represents — load or stress — and why. Then say how the cases change if a non-listed code comes back.
A web server answers 200 to a GET whose query string is exactly 8 digits, and 503 to anything else. Design the test cases for this API. Cover the positive and negative inputs you would derive with boundary-value analysis and equivalence partitioning, what you would do if a response differs from the two specified codes, and what kind of test 1000 simultaneous clients represents — load or stress — and why. Then say how the cases change if a non-listed code comes back.
Positive: exactly 8 digits → 200. Boundaries: 7 and 9 digits → 503; equivalence classes for 503: letters, symbols, empty, mixed digits/letters, leading zeros, spaced or negative input. A code other than 200/503 (e.g. 500) violates the spec — log it, file a defect, clarify the requirement and add cases for it, rather than passing. 1000 concurrent clients is a load test if it reflects expected traffic; it becomes a stress test only when it deliberately exceeds capacity to find the breaking point.
Common mistakes
- ✗Skipping boundary cases at 7 and 9 digits
- ✗Accepting an unspecified status code as a pass
- ✗Calling any concurrent test a stress test regardless of capacity
Follow-up questions
- →How do the cases change if the server checks the 8 digits against a database?
- →What would you test if the network between server and database drops?
MiddleDesignOccasionalFormulate negative scenarios for a POST request that creates a new user. List the distinct ways the request can be invalid — at the field level, the payload level, the auth level, and the security level — and state the expected response for each. Explain how negative API cases differ from simply re-running the happy path, and why testing them at the API layer is more thorough than only through the UI.
Formulate negative scenarios for a POST request that creates a new user. List the distinct ways the request can be invalid — at the field level, the payload level, the auth level, and the security level — and state the expected response for each. Explain how negative API cases differ from simply re-running the happy path, and why testing them at the API layer is more thorough than only through the UI.
Field level: missing required fields, wrong types, boundary or oversized values, invalid email format. Payload level: empty body, malformed JSON, wrong Content-Type. Data level: a duplicate user that already exists. Auth level: missing or invalid token. Security level: SQL or XSS injection. Each should return the right 4xx code, not a 500. The API layer reaches cases the UI silently blocks.
Common mistakes
- ✗Treating a resent valid request as a negative case
- ✗Expecting a 500 instead of a precise 4xx for invalid input
- ✗Forgetting auth and security (injection) negative cases
Follow-up questions
- →Why is a duplicate-user request a distinct negative case from a missing field?
- →Which negative cases can the UI silently prevent that the API cannot?
MiddleDesignOccasionalAn 'Age' field on a registration form accepts integers from 18 to 65 inclusive; out-of-range values raise a validation error. Design a set of test cases using boundary-value analysis: which specific values would you check and what is the expected result for each?
An 'Age' field on a registration form accepts integers from 18 to 65 inclusive; out-of-range values raise a validation error. Design a set of test cases using boundary-value analysis: which specific values would you check and what is the expected result for each?
Test each edge with three points: 17 (rejected), 18 (accepted), 19 (accepted) at the lower bound; 64 (accepted), 65 (accepted), 66 (rejected) at the upper. Add a typical mid value like 40 (accepted) and non-integer/empty inputs (rejected). Each case states the input and the expected accept-or-error result explicitly.
Common mistakes
- ✗Testing only the exact boundaries 18 and 65, not 17/19 and 64/66
- ✗Omitting invalid inputs (non-integer, empty) from the design
- ✗Not stating an explicit expected result per case
Follow-up questions
- →Why test 17 and 19 around the lower bound, not just 18?
- →How does this design combine with equivalence partitioning?
MiddleDesignOccasionalDesign critical acceptance test cases for the search bar on a shopping site's home page. Cover the positive checks first (it displays, accepts input, finds by name, by multiple words, by substring, in another language, by Enter and by the icon), then the negative and security checks (empty string, a single space, special characters, a very long string, an SQL-injection attempt, DOM tampering). Explain the ordering and why the security cases matter.
Design critical acceptance test cases for the search bar on a shopping site's home page. Cover the positive checks first (it displays, accepts input, finds by name, by multiple words, by substring, in another language, by Enter and by the icon), then the negative and security checks (empty string, a single space, special characters, a very long string, an SQL-injection attempt, DOM tampering). Explain the ordering and why the security cases matter.
Positive first: the bar renders and accepts input, search by exact name returns matching items, by multiple words, by substring, in another language, and triggers via both Enter and the icon. Then negative: empty string, lone space, special characters, an over-long string. Then security: an SQL-injection payload and DOM tampering must be safely rejected. Positive-before-negative confirms the core works before probing how it breaks.
Common mistakes
- ✗Forgetting negative and security cases
- ✗Starting with negative or security before the positive path
- ✗Skipping multi-word, substring, or other-language searches
Follow-up questions
- →Why must an SQL-injection payload in search be tested?
- →How would search test cases differ on mobile versus desktop web?
