Computer Science · 12th Grade

Active learning ideas

Quality Assurance and Testing Strategies

Active learning works for Quality Assurance and Testing Strategies because students often underestimate the complexity of testing until they apply techniques themselves. Writing tests, reviewing peers’ plans, and discussing edge cases forces them to confront gaps in their intuition about correctness and reliability.

• Common Core State Standards
• CSTA: 3B-AP-21
• CSTA: 3B-AP-23

• 30–60 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Collaborative Problem-Solving
• 60 min · Individual

Collaborative Problem-Solving: Unit Test Writing Workshop

Provide students with a set of functions with specifications but no implementation (or buggy implementations). Students write unit tests using a framework appropriate to their language (pytest, JUnit, or similar) before seeing or running the code. When they run their tests against the buggy implementations, failed tests become a structured debugging guide rather than a surprise.

Why is it impossible to prove that a piece of software is 100 percent bug free?

Facilitation Tip

During the Unit Test Writing Workshop, remind students that each test should verify one behavior using descriptive names like 'test_discount_negative_value_returns_zero' to reinforce clarity.

What to look for

Students pair up and exchange test plans for a common software feature (e.g., a login form). Each student acts as a reviewer, using a checklist to assess the completeness of their partner's plan, specifically looking for equivalence partitions, boundary values, and distinct functional vs. security test cases. Reviewers provide written feedback on coverage and suggest one additional test case.

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

Activity 02

• Expert Panel
• 50 min · Pairs

Peer Review: Test Plan Audit

Each student writes a test plan for a specified software feature, including test cases for normal operation, edge cases, and expected error conditions. Pairs then exchange plans and attempt to find uncovered cases , inputs or scenarios the original plan missed. The audit is documented; authors revise based on the gaps their reviewer identified.

What is the difference between testing for functionality and testing for security?

Facilitation Tip

For the Test Plan Audit, provide a shared rubric so reviewers focus on specific criteria like boundary values, security cases, and functional separation, not just length or style.

What to look for

Present students with a simple code snippet for a function (e.g., a function that calculates a discount based on purchase total). Ask students to write down 3-5 test cases using boundary value analysis and equivalence partitioning. Collect responses to gauge understanding of these specific techniques.

• Understand
• Apply
• Analyze
• Evaluate
• Self-Management
• Relationship Skills

Activity 03

• Think-Pair-Share
• 30 min · Pairs

Think-Pair-Share: Why Can't We Prove Software is Bug-Free

Students individually read a brief passage about the halting problem and test coverage limits. Each writes a two-sentence explanation in their own words for why 100% test coverage does not guarantee bug-free software. Pairs compare explanations, reconcile disagreements, then one explanation per pair is shared with the class for a whole-group synthesis.

Design a test plan for a software feature, including different types of tests.

Facilitation Tip

During the Why Can't We Prove Software is Bug-Free discussion, pause after each student contribution to connect their ideas to concrete examples like infinite input spaces or emergent behavior in their own capstone projects.

What to look for

Facilitate a class discussion using the prompt: 'Why is it impossible to prove that a piece of software is 100 percent bug free?' Guide students to articulate concepts like infinite input spaces, emergent behavior, and the difference between demonstrating presence and absence of errors.

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

Activity 04

• Jigsaw
• 55 min · Small Groups

Jigsaw: Testing Strategy Comparison

Expert groups each research one testing approach: unit testing, integration testing, system testing, regression testing, and security testing (input validation, common vulnerabilities). Groups reassemble in mixed teams to brief each other, then collaboratively map which strategy best catches which category of defect. The output is a decision guide for which tests to prioritize given a specific project context.

Why is it impossible to prove that a piece of software is 100 percent bug free?

Facilitation Tip

In the Testing Strategy Comparison Jigsaw, assign each group one strategy (unit, integration, system, regression) and require them to prepare a 2-minute pitch explaining its purpose, tools, and limitations using a provided template.

What to look for

Students pair up and exchange test plans for a common software feature (e.g., a login form). Each student acts as a reviewer, using a checklist to assess the completeness of their partner's plan, specifically looking for equivalence partitions, boundary values, and distinct functional vs. security test cases. Reviewers provide written feedback on coverage and suggest one additional test case.

• Understand
• Analyze
• Evaluate
• Relationship Skills
• Self-Management

A few notes on teaching this unit

Teach this topic by making testing visible and necessary. Start with student-written tests so they feel the frustration of incomplete coverage firsthand, then layer in concepts like equivalence partitioning and boundary values as tools to solve real problems. Avoid presenting testing as a checklist task; frame it as detective work where students must hunt for hidden assumptions and weak spots in their own logic.

Students will demonstrate understanding by creating targeted test cases, identifying gaps in coverage, and explaining why testing must be layered and ongoing. They will articulate limitations of unit tests alone and justify the need for multiple testing strategies in a full project.

---

Watch Out for These Misconceptions

• During the Unit Test Writing Workshop, watch for students who believe their job is done after all tests pass. Redirect them by asking: 'What happens when these components interact? Can you write an integration test to verify that?'

  Use this activity to show that unit tests verify isolated components, but integration failures require new tests. Provide a follow-up prompt: 'Write one integration test that combines two unit-tested functions and explain what behavior you are verifying that unit tests miss.'

• During the Peer Review: Test Plan Audit, watch for students who equate high test coverage with bug-free software. Redirect by asking reviewers to examine the test cases for equivalence classes and boundary values, not just line count.

  Have reviewers flag any test plan that relies solely on line coverage metrics. Ask them to suggest at least one additional test case that explores an edge case outside the happy path, such as a negative input or a boundary condition.

• During the Jigsaw: Testing Strategy Comparison, watch for students who treat security testing as a separate, late-phase activity. Redirect by asking each group to include security test cases in their strategy overview.

  Require each group to present one security-specific test example (e.g., SQL injection, buffer overflow) and explain why it belongs in their assigned testing strategy, not just in a final security review.

---

Methods used in this brief

• Collaborative Problem-Solving
• Expert Panel
• Think-Pair-Share
• Jigsaw