Computer Science · 11th Grade

Active learning ideas

Software Testing and Quality Assurance

Software testing cannot be learned through theory alone because students must experience the gap between intended and actual behavior. Active learning forces them to confront silent failures and practice systematic verification, which builds the habits that prevent rushed, error-filled capstone projects.

• Common Core State Standards
• CSTA: 3B-AP-16
• CSTA: 3B-AP-22

• 20–40 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Problem-Based Learning
• 35 min · Pairs

Bug Hunt: Find the Defects

Provide students with a short program (20-30 lines) that has three intentionally planted bugs covering different bug types: a logic error, an off-by-one error, and an edge case failure. Pairs write test cases designed to expose each bug, run them, and report which tests caught which defects.

Explain the importance of comprehensive software testing in the development cycle.

Facilitation Tip

During Bug Hunt, circulate and ask students to explain how they identified each defect, reinforcing the difference between crashing errors and silent logic failures.

What to look for

Students exchange test plans for a partner's capstone project. They should identify: Are there at least three distinct test cases for a core feature? Are expected outcomes clearly defined for each case? Provide one suggestion for an additional test case.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management
• Relationship Skills

Activity 02

• Problem-Based Learning
• 40 min · Pairs

Cross-Testing: Write Tests for a Partner's Code

Students swap their capstone project code with a partner. Each student reads the partner's code and writes five unit tests without seeing the original developer's test suite. Partners compare their test sets to identify which cases were missed by only one tester.

Differentiate between various types of testing (e.g., unit, integration, system, acceptance).

Facilitation Tip

When running Cross-Testing, provide a checklist of testing levels (unit, integration, acceptance) to guide students in writing tests that target the right scope.

What to look for

Ask students to write: 'One reason why integration testing is crucial, even if unit tests pass.' and 'One example of a bug that acceptance testing might catch but system testing might miss.'

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management
• Relationship Skills

Activity 03

• Problem-Based Learning
• 30 min · Small Groups

Test Plan Design Workshop

Groups receive a one-page feature specification (not yet implemented). Teams design a complete test plan covering unit tests, integration tests, and acceptance criteria before seeing any code. The class compares plans to identify which test categories were most commonly underspecified.

Design a test plan for a software application, including test cases and expected outcomes.

Facilitation Tip

In Test Plan Design Workshop, ask students to justify each test case by connecting it to a specific requirement or edge case from their project scope.

What to look for

Present students with a simple code snippet (e.g., a function to calculate a discount). Ask them to write one unit test case for it, including the input, the expected output, and a brief description of what the test verifies.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management
• Relationship Skills

Activity 04

• Think-Pair-Share
• 20 min · Pairs

Think-Pair-Share: Testing Levels Sorting Activity

Provide a deck of 20 test scenario cards. Students individually sort them into unit, integration, system, and acceptance categories, then compare with a partner and resolve disagreements. Contested cases are shared with the class to build a shared understanding of where the boundaries lie.

Explain the importance of comprehensive software testing in the development cycle.

Facilitation Tip

Use Think-Pair-Share to slow down the sorting activity by requiring students to defend their category choices with examples from their own code.

What to look for

Students exchange test plans for a partner's capstone project. They should identify: Are there at least three distinct test cases for a core feature? Are expected outcomes clearly defined for each case? Provide one suggestion for an additional test case.

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

A few notes on teaching this unit

Ground this work in real student artifacts. Collect anonymized snippets from past capstone projects that show common silent failures, then let students analyze these in Bug Hunt. This makes the abstract concrete. Avoid starting with definitions alone: students need to feel the frustration of a bug that passes silently before they’ll value testing. Research shows that students who write tests before coding write fewer bugs overall, so scaffold test-first thinking early, even if you don’t adopt full TDD.

Students will move from seeing testing as a chore to recognizing it as an essential design tool. They will write tests that catch real bugs, articulate why certain test cases matter, and explain how different testing levels serve different purposes in quality assurance.

---

Watch Out for These Misconceptions

• During Bug Hunt, watch for students assuming that if the program runs without crashing, the feature works correctly.

  Use the provided buggy code snippets in Bug Hunt that return plausible but wrong answers for common mistakes like off-by-one errors or incorrect boundary conditions. Ask students to document both the crash and the silent failure cases they find, comparing how each reveals a different kind of defect.

• During Cross-Testing, watch for students treating testing as an afterthought rather than a design activity.

  Require students to write a short rationale for each test case they create, linking it to a specific requirement or potential failure mode. Then, have them exchange not just code but also their rationales to see how their partner’s test choices differ from their own.

• During Test Plan Design Workshop, watch for students equating thoroughness with the number of test cases rather than their coverage.

  Have students use a coverage tool to run their test plans against sample code. When they see low coverage percentages, ask them to redesign their test plans to target uncovered branches and edge cases, emphasizing the quality of paths over the quantity of cases.

---

Methods used in this brief

• Problem-Based Learning
• Think-Pair-Share