Writing Test Plans

NOTE

Mr. Gordon co-developed this summary using ChatGPT, then edited it for clarity and length.

Below is a short guide to three useful test-plan categories you’ll use when authoring programs.

Examples come from The Cell Sell, where we compared two phone plans using daytime, evening, and weekend minutes.

Typical cases

These are normal, expected inputs that the program should handle easily. They help verify the main logic is correct.

A few examples:

Day	Eve	Wknd	Why this case matters	Expected behaviour
75	40	20	Well under any daytime free‑minute thresholds	No overage; compute base totals and report winner
320	30	10	Daytime clearly exceeds free block	Daytime overage charged; verify calculation branch for overage
251	10	60	Realistic mix that should produce a clear winner	Totals differ; message shows the cheaper plan
162	61	66	Realistic mix designed to tie	Program prints a tie message

TIP

Accuracy – since costs are in cents, consider computing in cents as integers to avoid rounding issues with floating-point values, then convert to dollars and cents for output.

Boundary conditions

Boundaries are “edges” where logic flips from one branch to another. Testing here catches off-by-one errors—very common when code contains selection or conditional statements.

Inputs (Day, Eve, Wknd)	Boundary being tested	What should happen
(0, 0, 0)	All zeros	Both plans should total $0.00; tie message
(100, 0, 0)	Plan A threshold exactly	Last free minute; no overage charged for A
(101, 0, 0)	Plan A just past threshold	First charged minute for A; verify off‑by‑one handling
(250, 0, 0)	Plan B threshold exactly	Last free minute; no overage charged for B
(251, 0, 0)	Plan B just past threshold	First charged minute for B; verify off‑by‑one handling
(99, 0, 0) vs (100, 0, 0) vs (101, 0, 0)	Just‑under/at/over (Plan A)	Totals should step from no charge → no charge → small charge
(249, 0, 0) vs (250, 0, 0) vs (251, 0, 0)	Just‑under/at/over (Plan B)	Totals should step from no charge → no charge → small charge
Tie case ±1 minute	Tie edge	Exact tie flips to a winner when 1 minute moves across a threshold

Invalid inputs

These are inputs your program shouldn’t accept.

You decide how to handle them (reject, re-prompt, or sanitize) and test that your handling works.

Input example	Why invalid	Recommended handling
Day = −5	Minutes cannot be negative	Show clear error and re‑prompt until non‑negative
Eve = “ten”	Not a number	Show error and re‑prompt for a whole number
Wknd = 12.5 (if only whole minutes allowed)	Not an integer	Either round/reject; be consistent and document the choice
(very large) Day = 2,000,000	Stress test / overflow risk	Still compute safely; avoid crashes and format output correctly
Blank input (just Enter)	Missing data	Keep asking until valid data is entered

Typical handling strategies:

• Validate that each input is a non‑negative integer before calculation.
• If invalid, show a clear message and re‑prompt.