You're testing a function that approves a loan only when the applicant's age is between 18 and 65 inclusive. How would you systematically choose test cases for it, and why does that beat just writing a few examples you think of?

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses whether the candidate can apply equivalence partitioning and boundary value analysis deliberately, justify why boundaries are where defects cluster, and contrast a systematic technique with ad-hoc example-picking — a core senior test-design competency.

What to say

• Partition the input space (equivalence partitioning): below valid (under 18), valid (18-65), and above valid (over 65), plus an invalid-type/empty partition — one representative per class avoids redundant tests while covering each behavior once.
• Add boundary value analysis: test right at and just around each edge — 17/18/19 and 64/65/66 — because off-by-one and wrong comparison operators (< vs <=) are the most common defects and they hide exactly at the boundaries, not in the middle of a partition.
• Justify it over ad-hoc picking: a systematic technique gives defensible, minimal, repeatable coverage of the behavior and forces you to include the negative and edge cases an 'examples I thought of' approach reliably misses; also include invalid inputs (negative, non-numeric, null) and the documented behavior for them.

What to avoid

• Testing only a couple of mid-range valid ages and calling it done, missing the boundaries where comparison bugs live.
• Listing dozens of redundant valid ages (30, 31, 32...) that all exercise the same partition and add no information.
• Ignoring invalid and out-of-type inputs (negative, zero, non-numeric, null) and the specified behavior for them.

Example answers

Strong: I'd use equivalence partitioning plus boundary value analysis rather than random examples. The partitions are: below valid (under 18), valid (18 to 65), above valid (over 65), and invalid inputs. One representative per partition covers each behavior once. Then I attack the boundaries, because that's where the bugs are: 17, 18, 19 and 64, 65, 66 — those catch a < where it should be <= or an off-by-one on the inclusive range. I'd also test invalid inputs — negative, zero, non-numeric, null — against the documented behavior. The reason this beats a few examples I happen to think of is it's minimal, repeatable, and it forces the negative and edge cases in, which ad-hoc picking almost always skips.

Weak: I'd test a few ages — say 25, 40, and 60 to confirm they're approved, and maybe 10 and 80 to confirm they're rejected. That covers the valid and invalid ranges.