What are the four input dimensions used to vary test cases, and what does each mean?
- Positive testing feeds valid input and confirms the happy path works.
- Negative testing feeds invalid input and confirms the system correctly rejects it.
- Boundary testing checks values at the edges of a valid range, since bugs cluster there.
- Data-driven testing runs one test function repeatedly over a table of different inputs and expected outputs.
The long answer
These four are independent of test level, meaning you can apply any of them at the unit, integration, system, or end to end level — they describe how you vary the input, not how much of the system you’re touching.
Positive testing, also called the happy path, feeds valid, expected input and checks the system behaves correctly — for example logging in with the correct username and password.
Negative testing deliberately feeds invalid or unexpected input — wrong password, missing field, malformed email — and checks the system correctly rejects it or handles it gracefully, not that it crashes.
Boundary testing, using boundary value analysis, tests values right at the edges of a valid range, since defects cluster there far more than in the middle of the range. The standard technique is three values per edge: one below, one at, and one above. For a valid range of 18 to 60, that means testing 17, 18, 19 at the lower edge, and 59, 60, 61 at the upper edge — this is the canonical answer expected instantly in interviews.
Data-driven testing means writing one test function once, then feeding it a list or table of different input and expected-output pairs, so the same logic runs multiple times, once per data row, instead of duplicating near-identical test functions. In Pytest, this is the parametrize decorator.
Which level do these mostly live at? Overwhelmingly unit level — see Concept 2’s “how to actually decide what to write, at each level” section for the full reasoning. Short version: unit tests are cheap and isolated, so they absorb the full positive/negative/boundary/data-driven treatment; integration and system tests don’t repeat this, since those values were already proven correct below them.
Confusing boundary testing with just "testing a big or weird value" — the correct standard answer is specifically three values straddling each edge of the valid range, not just the extreme value alone.
