3. Equivalence partitions and representative data

Equivalence partitioning groups inputs expected to follow the same rule. For a required integer page size from one to three, valid integers, below-range numbers, above-range numbers, fractions and nonnumeric values exercise different reasons for acceptance or rejection.

The grouping comes from the contract, not merely from how values look. A numeric string may be valid at a URL parser and invalid at an internal numeric function. State which boundary is under test before deciding that two inputs belong to the same class.

The worked table uses one representative from several classes and states expected validity. It targets a numeric domain validator, not the HTTP query-string parser. That keeps a string two intentionally different from the number two.

Representatives reduce redundant work but do not prove every member behaves identically. Choose additional examples when the implementation or past defects suggest a split, such as unsafe large numbers, leading signs or locale-specific text parsing at another boundary.

The weak table checks only valid values one, two and three. Those cases may be useful, but they provide no evidence about rejecting fractions or out-of-range values. A broad suite can still have a narrow behavioral surface when all inputs follow the same successful path.

Do not equate one test per class with complete coverage of every business risk. Partitions help select data; boundaries, state, permissions and interactions may require other techniques. Keep the claim limited to the chosen input rule.

Create a representative table for a numeric years-of-experience value accepting integers zero through fifty. Include a valid interior value, below and above range, a fraction and a string. Begin with the accepted domain before adding invalid classes.

Give each row a reason as well as expected validity. Do not use zero as a missing-value proxy; it is explicitly valid here. The independent exercise changes the range and meaning so you must transfer the technique rather than copy page-size values.

Step 1: Write the accepted integer range. Step 2: Add a distinct reason for each rejected class.

The solution preserves zero and rejects the invalid categories for separate reasons. Its expected results are hand-authored. The local domain verifier runs the table against the documented validator and also checks that a weakened integer rule is detected.

A passing table supports the represented classes only. If the real endpoint accepts text, add parser-specific classes in a separate table. This prevents a tester from confusing the internal validation contract with the external transport representation.

In interviews, explain how you found the classes and why one representative is useful. Identify an input that would require splitting a class. Distinguish rejecting a fraction from checking the lower bound even though both produce an invalid result.

Next, concentrate examples around boundaries, where small comparison mistakes often change behavior. Keep the numeric domain explicit so a plus-or-minus-one rule is not applied blindly to continuous values or text.

Optional stretch — after the core task works: Add null and a very large number as separate reviewed cases.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.