Test design techniques

how to choose what to test

What are equivalence classes?

We split input data into groups where the system behaves the same, and take one value from each group, valid and invalid.

Example: a transfer amount of 1–10,000 UAH. Classes: less than 1 (invalid), 1–10,000 (valid), more than 10,000 (invalid), and also non-numeric values and an empty field.

In an interview: We split input data into groups where the system behaves the same, and test one representative from each, valid and invalid. For example, for an amount from one to ten thousand: a value in the range, below, above, text and an empty field. That reduces the number of tests without losing coverage.

What is boundary value analysis?

Bugs most often live at the boundaries of ranges, so we test values at the boundary and next to it.

For 1–10,000: 0, 1, 2 and 9,999, 10,000, 10,001. For money, fractional boundaries also matter: 0.99, 1.00, 1.01 and 10,000.00 / 10,000.01.

In an interview: Errors are most often at the boundaries, so I test the boundary itself and the value next to it on both sides. For a range from one to ten thousand that is zero, one, two, and nine thousand nine hundred ninety-nine, ten thousand, ten thousand and one. For money I add fractional boundaries in cents.

What is a decision table and when do you use it?

When the result depends on a combination of several conditions. Each column is a combination of conditions and the expected action.

Condition / rule	1	2	3	4
Sufficient funds	Yes	Yes	No	No
Limit not exceeded	Yes	No	Yes	No
Result	Transfer	Refusal: limit	Refusal: funds	Refusal: funds

The table immediately shows missed combinations and questions for the requirements: which error to show when both conditions are not met?

In an interview: I use a decision table when the result depends on a combination of conditions. I write out all the combinations and the expected result for each. Besides test cases, this often gives questions for the requirements, for example which error to show when two conditions fail at once.

What is state transition testing?

For objects that pass through states: an order, a payment, an account. We build a diagram of states and transitions and test the valid transitions, as well as the invalid ones: that the system doesn't allow them.

Payment:
  Created → Pending → Authorized → Captured → Settled
                    ↘ Declined
  Captured → Refunded

Invalid transitions for a test:
  Declined → Captured    (a declined payment can't be debited)
  Refunded → Refunded    (a double refund)
  Created  → Settled     (skipping steps)

In an interview: For entities with states, such as payments, orders and accounts, I draw a state diagram and check all the valid transitions. And most importantly the invalid ones: that a rejected payment can't be debited, and a refunded one can't be refunded a second time.

What is pairwise testing?

When there are many parameters and checking all combinations is impossible. Most defects are caused by the interaction of two parameters, so it is enough to cover all pairs of values, not all combinations.

Example: 3 browsers × 3 OSes × 3 languages × 2 account types = 54 combinations; pairwise reduces it to ~9–12. They are generated with tools like PICT or online generators.

In an interview: Pairwise helps when there are too many parameters to try all combinations. Most bugs come from the interaction of two parameters, so I cover all pairs of values. For example, fifty-four combinations of browsers, OSes and languages shrink to about ten, and I generate them with a tool.

What are error guessing and experience-based checklists?

Experience-based testing: where does it usually break? Empty fields, spaces at the start and end, very long strings, special characters and emoji, a double click, the Back button, refreshing the page in the middle of a process, losing the network, several tabs open at once.

This complements formal techniques, not replaces them.

In an interview: Error guessing is when from experience I know the typical places of breakage: empty fields, special characters, a double click, refreshing the page in the middle of a process, a dropped network. I use it together with formal techniques, not instead of them.

Equivalence classes and boundary values: age 18–65

Equivalence classes split input data into groups where the system behaves the same, so one value from each class is enough. For the field "age 18–65" we have a valid class 18–65 and two invalid ones: less than 18 and more than 65. Representatives: 30, 10 and 80.

Boundary values check the boundaries, because that is where developers most often make mistakes. For the two-point approach I take 17, 18, 65, 66; for the three-point one 17, 18, 19, 64, 65, 66. Expected: 18 and 65 are accepted, 17 and 66 are not.

Additionally I check invalid data types: an empty field, 0, a negative number, a fractional 18.5, letters, spaces, special characters and a very long number. It is also worth clarifying with the analyst whether the boundaries are inclusive, because this is a frequent ambiguity in requirements.

Decision table and state transition

A decision table is used when the result depends on a combination of several conditions. For example a discount: whether the user is VIP and whether the order amount is more than 1000 hryvnias. We build a table with all combinations of conditions and the expected actions, so missed or contradictory rules are visible.

For n binary conditions there will be 2 to the power n combinations, so the table is often reduced by merging rules where some condition doesn't affect the result. This technique is useful for business rules, tariffs, access rights.

State transition is applied when a system has states and transitions between them. An example is an order: New → Paid → Shipped → Delivered, with a possible transition to Cancelled. We test all the valid transitions and check that the invalid ones are forbidden, for example it is impossible to cancel an already delivered order.