Computer Science · Grade 12

Active learning ideas

Quality Assurance and Testing

Active learning works for quality assurance and testing because students need hands-on practice to see how bugs behave and how tests reveal them. When students write tests before or alongside code, they experience firsthand why systematic checks prevent later failures.

• Ontario Curriculum Expectations
• CS.SE.9
• CS.P.25

• 25–50 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Peer Teaching
• 35 min · Pairs

Pairs: TDD Implementation

Pairs select a simple function requirement, like calculating prime numbers. They write a failing unit test first, code the minimum to pass, refactor, and repeat for three features. Debrief on how tests shaped their design.

How does Test-Driven Development change the way a programmer approaches a new problem?

Facilitation Tip

During TDD Implementation, circulate and ask pairs to explain their test-first reasoning aloud so hesitant students hear the logic repeated.

What to look for

Provide students with a simple, buggy function. Ask them to write one unit test that would fail due to the bug and then describe the debugging step they would take to find the error.

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

Activity 02

• Peer Teaching
• 45 min · Small Groups

Small Groups: Debug Relay

Provide buggy code with mixed logic and runtime errors. Groups divide tasks: one identifies errors, another writes tests, a third fixes and verifies. Rotate roles twice, then share solutions class-wide.

What is the difference between a bug that is a logic error and one that is a runtime error?

Facilitation Tip

For Debug Relay, provide code with subtle logic errors and limit each group to 90 seconds per station to build urgency and focus.

What to look for

Pose the question: 'Can software ever be 100 percent defect-free?' Facilitate a class discussion where students use examples from real-world software failures to support their arguments, referencing concepts like testing limitations and complexity.

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

Activity 03

• Peer Teaching
• 50 min · Whole Class

Whole Class: Integration Testing

Build a class project incrementally, like a student database. Project one module at a time on the board, write integration tests as a group, run them live, and fix failures together while noting interactions.

Can a software product ever be 100 percent free of defects?

Facilitation Tip

In Integration Testing, give students mismatched module stubs to force them to negotiate interfaces before writing tests.

What to look for

Students pair up and exchange code snippets they have written. Each student reviews their partner's code, identifying potential bugs and suggesting one specific unit test they would write to catch a hypothetical error. Partners provide feedback on the clarity and relevance of the suggested tests.

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

Activity 04

• Peer Teaching
• 25 min · Individual

Individual: Personal Test Suite

Students pick their recent project code, write 5-7 unit tests covering edge cases, run them, and log fixes. Submit suites for peer review next class.

How does Test-Driven Development change the way a programmer approaches a new problem?

What to look for

Provide students with a simple, buggy function. Ask them to write one unit test that would fail due to the bug and then describe the debugging step they would take to find the error.

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

A few notes on teaching this unit

Start with concrete examples: show a banking transaction that fails because a rounding error wasn’t tested. Avoid abstract lectures on test coverage metrics; instead, have students measure coverage themselves after writing tests. Research shows hands-on debugging builds stronger mental models than slide decks on defect taxonomies.

Successful learning looks like students confidently writing tests that uncover hidden bugs and discussing trade-offs between different testing approaches. By the end of these activities, students should explain why testing is not a phase but a continuous practice in software development.

---

Watch Out for These Misconceptions

• During TDD Implementation, watch for students writing code first and then retrofitting tests.

  Provide starter test skeletons with failing assertions that guide students to write code only after tests exist, reinforcing the test-first mindset.

• During Debug Relay, watch for students assuming all errors are syntax issues visible in the compiler.

  Include logic errors that pass compilation but fail at runtime, forcing students to use breakpoints and variable watches to trace execution.

• During Integration Testing, watch for students believing a passing unit test guarantees module compatibility.

  Give students modules with conflicting assumptions about data formats, so they must write integration tests that expose interface mismatches.

---

Methods used in this brief

• Peer Teaching