How do you apply equivalence partitioning to the output domain rather than to input values?

## The domain does not have to be the input Equivalence partitioning is usually taught on input fields, and that framing sticks so hard that many candidates believe it is part of the definition. It is not. The technique is: divide a domain into classes the software treats as equivalent, and test one member of each. The **output domain** — the set of distinct results the software is specified to produce — partitions just as well, and sometimes better. ## Why the input side alone can under-cover Consider a hospital appointment scheduler whose booking request carries a handful of fields. Partitioning those fields might give you a dozen valid classes. But the specification says the request can end in only a few distinct outcomes: the appointment is booked, the patient is placed on a waitlist, the clinic is full for that date, a referral is required before booking, or the request is refused as invalid. If you partition inputs only, it is entirely possible for eight of your twelve valid cases to end in *booked*, one in *refused*, and for *waitlisted*, *clinic full* and *referral required* never to appear at all — because reaching them depends on the state of the clinic's calendar and on the patient record, not on any value in the request. The class table looks thorough and the outcome coverage is poor. Partitioning the outputs makes that gap visible immediately: five outcome classes, three with no case. ## How to do it 1. **Enumerate the distinct outcomes** the specification allows, including refusal categories and any explicitly-described empty or degenerate result. Two outcomes belong to one class only if the software is meant to produce genuinely the same result for both. 2. **For each outcome class, ask what it takes to get there.** The answer is a combination of request values and preconditions — a clinic whose remaining slots for the day are zero, a patient record with no referral on file. 3. **Design one case per outcome class**, and record the setup as part of the case, because for output partitioning the setup is usually the load-bearing part. 4. **Look at the leftovers.** Outcomes you cannot reach at all are a finding in themselves: either the specification names a result the implementation cannot produce, or the precondition is undocumented. Working backwards is the difficult step, and it is the honest limitation of the technique: the mapping from inputs to outcomes is many-to-one, and it is not always invertible by inspection. An outcome produced only by a rare timing or a long-accumulated data state may need production observation rather than design-time reasoning to reproduce. ## The same move on derived values The idea generalises past the visible response. Anything the specification classifies can be partitioned: a computed fee that falls into free, standard or surcharged; a patient record that ends in one of a few defined lifecycle states; the category of a message the system emits. In each case the classes come from the specification's own vocabulary of outcomes rather than from field ranges. The discipline that keeps this useful is the same as on the input side — the classes must be disjoint and must cover everything the specification allows, including the results nobody enjoys thinking about. ## Using both sides together Input and output partitioning ask different questions, and each catches what the other misses. Input partitioning asks *did I feed it every kind of thing it accepts?*, which is the question that finds mishandled and unvalidated input. Output partitioning asks *did I ever see it do each of the things it can do?*, which is the question that finds unreachable, mislabelled and never-exercised results. A case designed from one side usually satisfies part of the other, so the practical routine is to build the input class table first, map each case to the outcome it produces, and then add cases only for the outcome classes that nothing reached. That leaves a suite where every input class and every outcome class has at least one case, without inflating the count by doing both exercises independently. ## Why it is asked Interviewers rarely gate an offer on this. They ask it as a probe after a good input-side answer, because a candidate who can partition an output domain has understood that the technique is about classes of specified behaviour, not about splitting numeric ranges — which is precisely the understanding that transfers when the input is not a number at all.