Equivalence partitioning: one value speaks for many

Every technique starts from the test basis, here the checkout rules the team agreed on. In this course, all money is in integer cents, so $5.00 is 500. Integers avoid rounding errors that floating-point numbers bring.

Checkout rules (customer app)
Cart total allowed:  500 to 50000 cents inclusive
  below 500  -> "Add $5.00 to check out"
  above 50000 -> blocked
Delivery fee:        150 cents when the cart total is below 2500, free from 2500
Quantity per line:   1 to 20, whole numbers only

An equivalence partition is a group of inputs the software should handle the same way. If the checkout charges the fee correctly for a cart of 1,200 cents, it will almost certainly charge it correctly for 1,300 too, because the same line of code decides both. So you test one value per partition and move on.

For the cart total, read the rules and draw the groups. There are two valid partitions: 500 to 2499 (allowed, fee 150) and 2500 to 50000 (allowed, free delivery). There are two invalid partitions: below 500 and above 50000. Four partitions, so four tests, for example 300, 1200, 3000 and 60000. Each of those is a test case: an input plus the result you expect.

Do the same for quantity per line. Valid: 1 to 20. Invalid: 0 and below, 21 and above, and a value that is not a whole number, such as 2.5. That last one is easy to forget. The rule says "whole numbers", so "not whole" is its own partition, and someone has to decide what the app does with it.

Two habits make partitions useful. First, test invalid partitions one at a time. If a test sends quantity 0 and a cart of 300 together and gets an error, you cannot tell which rule produced it; the second problem hides the first. Second, partitions come from the rules, not from the screen. A quantity stepper that only shows 1 to 20 does not stop the API from receiving 25, so the invalid partitions still need tests (Testing APIs and data does that below the UI).

Boundary value analysis: bugs live at the edges

Partitioning picks values from the middle of each group. Most bugs are not in the middle. A developer reads "free from $25.00" and types cart > 2500 instead of cart >= 2500. The middle values 1200 and 3000 still pass. Only a cart of exactly 2500 shows the bug. Boundary value analysis (BVA) targets these mistakes. A boundary value is the smallest or largest value of an ordered partition, so every edge between two partitions has two boundary values, one on each side.

The ISTQB Foundation syllabus (version 4.0) describes two forms. In 2-value BVA, for each boundary value you test the value itself and its closest neighbour in the next partition. At the free-delivery edge, that means 2499 and 2500. In 3-value BVA, for each boundary value you test the value and both its neighbours. Around the same edge, that gives 2498, 2499, 2500 and 2501. Here is the full set for the checkout rules:

Why would you ever pay for the extra values of 3-value BVA? Because some bugs pass both 2-value tests. Suppose a refactor turns "free from 2500" into "free when the cart equals 2500". At this edge, 2499 still pays the fee and 2500 is still free, so both 2-value tests pass. The 3-value test at 2501 expects free delivery, gets a fee, and catches it. Use 2-value BVA by default and 3-value BVA on the rules where a mistake costs the most, such as money and limits.

Boundaries hide in places that are not obviously numbers too. Dates have them (a slot that closes at 18:00, a code that expires at midnight in which time zone?), lists have them (an empty cart, the 20th line), and text has them (a promo code field that accepts 12 characters). Wherever a rule says "at least", "up to", "from", "before" or "maximum", write down the edge and the values on each side.

Decision tables: when rules combine

Partitions and boundaries work on one input at a time. Some rules depend on several conditions together. The discount code FRESH10 gives 10% off when the cart total is at least 2000 cents, the customer has never ordered before, and the order does not already have the staff discount. A decision table lists every combination so none is forgotten.

Write the conditions as rows at the top and the actions as rows at the bottom. Each column is one decision rule. With three true-or-false conditions there are 2 × 2 × 2 = 8 columns. Now look for columns where one condition already decides the result. If the cart is under 2000, the code is refused whatever the other two conditions say, so four columns collapse into one, marked with "–" for "does not matter". If the cart is big enough but this is not the first order, the staff discount does not matter either, so two more columns collapse. Eight columns become four:

Each column is a test case, so full decision table coverage here is four tests. The table also does something more valuable: it forces questions. Column R4 says a returning staff member with a $15.00 cart sees the "Spend $20.00" message. Is that the message the product manager wants, or should it say "first order only"? Collapsing a column is a claim that the other conditions do not matter, so check that claim with the team before you rely on it. Other questions fall out too. Is the 2000 checked before or after the delivery fee? If a customer applies the code and then removes items until the cart is 1800, does the discount disappear? Those questions are cheap in refinement and expensive after release.

Techniques combine. The condition "cart total 2000 or more" has its own edge, so add two runs: column R1 at exactly 2000 and column R4 at 1999. One design, two techniques, six tests, each one aimed at a specific way the code could be wrong.

State transition testing: what can happen next

An order is not one input. It moves through states, and events move it from one state to the next. The checkout rules for Mangrove orders are:

created         --pay-->        paid             (card or wallet)
created         --chooseCod-->  confirmed-cod    (cash on delivery)
paid            --pick-->       picking
confirmed-cod   --pick-->       picking
picking         --dispatch-->   out-for-delivery
out-for-delivery --deliver-->   delivered
created, paid, confirmed-cod, picking  --cancel-->  cancelled
paid            --refund-->     refunded         (refunds only from paid)

That is 11 valid transitions: three from created, three from paid, two from confirmed-cod, two from picking and one from out-for-delivery. Every other pair of state and event is an invalid transition, and the system must refuse it: cancel an order that is already out for delivery, refund a cash-on-delivery order that was never paid, pay twice for the same order. Invalid transitions are where the expensive bugs live. A double payment or a refund of money you never received costs real money, and both look fine in every screen until someone tries the wrong event in the wrong state.

A state model lets you measure what you tested. The syllabus names three levels. All states coverage visits every state at least once. Valid transitions coverage, also called 0-switch coverage, exercises every valid transition at least once; here, all 11. All transitions coverage adds an attempt at every invalid transition too. When you try invalid transitions, try only one per test case: if the first wrong event is wrongly accepted, it changes the state and can hide what the second one would have shown.

A useful way to find invalid transitions is a state table: states down the side, events across the top, the resulting state in each cell. Every empty cell is an invalid transition you could try. Eight states and seven events give 56 cells, and only 11 are valid, so you cannot try all 45 invalid ones in every release. Pick by risk: anything that moves money (pay, refund), anything the customer can trigger from the app (cancel), and anything a rider or picker can trigger at the wrong moment (deliver before dispatch).

How much is enough: coverage, mutants and pairs

Each technique comes with its own measure of coverage: partitions exercised out of partitions found, boundary values tested out of boundary values found, decision table columns run out of feasible columns, transitions exercised out of transitions in the model. These numbers are useful because they are honest about scope. "100% 2-value BVA coverage of the cart rules" tells a reviewer exactly what you tried and what you did not. They are not a promise of no bugs: 100% coverage of a model with a missing rule still misses the rule.

A second way to judge a set of tests is to ask which bugs it would catch. A mutant is a copy of the code with one small planted mistake, such as > where the rule needs >=. If at least one test fails on the mutant, the tests "kill" it. Mutation testing tools generate mutants automatically from real code; in this lesson's practice, the checker plants typical edge mistakes and tells you which ones your test cases miss. It is a direct way to see why 1200 and 3000 are weak tests for the fee rule, and 2499 and 2500 are strong ones.

Finally, some features are a combination problem. Checkout must work for 3 payment methods (card, wallet, cash on delivery) × 2 slot types (Now, Later) × 3 device groups (a cheap Android phone, a newer Android phone, an iPhone). That is 18 combinations. Pairwise testing picks a smaller set in which every pair of values (card with Later, wallet with the cheap phone, and so on) appears at least once. For these three parameters, 9 tests cover every pair. It works because many combination bugs need only two things to line up. Use a pairwise tool or a spreadsheet to build the set, then add the few full combinations that matter most by risk, such as cash on delivery at the festival rush on the cheap phone.