Teaching Proving It Works: Designing Test Cases in Grades 11-12 (Level 2): Oklahoma Standard L2.AP.PD.05

Teaching software test cases in grades 11-12 (level 2) does not have to be complicated. Picture a QA engineer writing a structured test plan covering typical, boundary, and invalid inputs before a release is approved. That kind of thinking is exactly what Oklahoma's grades 11-12 (level 2) computer science standard L2.AP.PD.05 asks students to practice — and it is very teachable with the right materials. This post walks through what the standard means, the misconceptions students bring to it, and discussion starters you can use tomorrow, whether you teach in a classroom or at your kitchen table.

What Does Standard L2.AP.PD.05 Actually Ask?

Develop and use a series of test cases to verify that a program performs according to its design specifications. — Oklahoma Academic Standards for Computer Science (February 2023)

In plain language: This standard asks students to design a set of specific checks — typical examples, tricky edge values, and the exact boundaries of a rule — and use them to prove whether a program truly follows the rules it was supposed to follow.

In student-friendly terms, the learning target is: "I can develop a series of test cases — covering typical, boundary, and edge/invalid inputs — and use them to verify whether a program performs according to its written design specification."

What Students Should Be Able to Do

• I can read a design specification and identify its typical, boundary, and invalid-input requirements.
• I can write a test case with a specific input and a predicted expected output before running the program.
• I can compare expected output to actual output to determine whether a test case passes or fails.
• I can explain what a failing test case reveals about a defect and design a regression test to protect a fix.

Along the way, students pick up the working vocabulary of the topic: testcase, specification, input, expected, actual, boundary, edgecase, defect, debugging, regression, coverage, assertion, validate, anomaly.

Software Test Cases: Misconceptions to Watch For

These are the wrong turns students reliably take with this standard — knowing them ahead of time is half the lesson plan. Each correction strategy below comes straight from the unit's teacher guide (the paragraph and activity references point into the unit itself).

1. "If a program runs without crashing, it must be correct."

Return to paragraph 1's distinction between running and verifying. Show a program that runs successfully but produces the wrong numeric output for a specific test case to demonstrate that 'runs without error' and 'meets the specification' are not the same claim.

2. "Testing a few typical, everyday inputs is enough to trust a program."

Use the paragraph 3-4 grade calculator example. Show that a program passing three typical scores can still fail at the exact boundary of 60, and have students find the specific off-by-one comparison that a boundary test would catch.

3. "A failed test case means the student did something wrong."

Reframe using paragraph 6: a failed test case is valuable, precise information pointing at a defect in the program, not a mistake by the tester. Practice restating a failure as 'this input reveals a defect in X,' not 'I got it wrong.'

4. "Once a bug is fixed, there is no need to test the rest of the program again."

Connect to paragraph 8's regression discussion. Walk through the scenario where fixing the 60-point boundary accidentally changes how negative scores are handled, and show why re-running the full test series, not just the new test, is the only way to catch that.

Discussion Starters You Can Use Tomorrow

• Why is predicting expected output before running a program more rigorous than checking whether the output 'looks right' afterward?
• Why do boundary values catch more real defects than typical values, even though boundary values are used far less often in everyday use?
• Describe a real-world process outside computer science (a recipe, a safety rule, a sports rule) where testing the 'edge cases' matters just as much as it does for software.

Bringing It Home

This topic is a natural one for families. One ten-minute activity to try: Together, pick a household rule with a number in it (a screen-time limit, an oven temperature, a recipe's cooking time) and have your student describe three specific tests they would run to prove the rule is being followed correctly: a normal example, the exact edge of the rule, and a case that should clearly break the rule. There are no wrong answers — the goal is hearing their reasoning about the edges.

Where This Leads

Students who can develop a series of test cases — covering typical, boundary, and edge/invalid inputs — and use them to verify whether a program performs according to its written design specification are building skills used every day in quality assurance / test engineering, software engineering, DevOps / release engineering, product management, and AI / machine learning engineering.

See the Unit in Action

Get the Complete L2.AP.PD.05 Unit

I built a complete, no-prep unit for this standard — Proving It Works: Designing Test Cases to Verify a Program's Specifications — covering 3-4 days of instruction across 43 pages:

• Teacher guide — day-by-day pacing, misconceptions to watch for, discussion questions, differentiation for support / ELL / extension, and a 4-point rubric
• Student learning target page — a kid-friendly "I can" statement with success criteria
• Full content lesson with 3 embedded "Check Your Understanding" checkpoints
• 12-question assessment (6 multiple choice, 4 true/false, 2 short answer) with a complete answer key, explanations, and exemplar responses
• Group activity — "Design the Test Plan: Verifying a Program Against Its Specification" (25-30 minutes)
• Individual activity — "My Test Case Portfolio" (20-25 minutes)
• Crossword and word search built from all 14 vocabulary terms (with answer keys)
• Family connection letter — a plain-language page for parents, with dinner-table questions and a 10-minute home activity
• Certificate of achievement — ready to sign and send home
• Specification Card Set: Designing Test Cases (separate printable, 2 pages)
• Reference Notes: Designing and Running Test Cases (separate printable, 2 pages)
• My Test Case Portfolio (separate printable, 2 pages)

Get Proving It Works: Designing Test Cases on Teachers Pay Teachers →

Also aligned to CSTA 3A-AP-18: Systematically test and refine computational artifacts, taking into account a variety of factors, including efficiency, correctness, and usability.

Every Sooner Standards resource is built directly from the official Oklahoma Academic Standards for Computer Science (February 2023) — standard text verified, never paraphrased from memory.