Capstone Software Development: Testing and Quality Assurance

Active learning works for testing and quality assurance because students must experience firsthand how thorough testing prevents real-world failures. When they role-play as both programmers and testers, they internalize the mindset that code must prove its own correctness under stress and scrutiny. This hands-on approach builds habits that textbooks alone cannot teach.

• Grade 11
• Computer Science
• 4 activities
• 30 min–50 min

Learning Objectives

1. Design and implement unit tests for at least three functions within their capstone project, ensuring all specified test cases pass.
2. Evaluate the usability of their capstone software by conducting a user acceptance test with at least two peers, identifying and documenting at least two areas for improvement.
3. Compare and contrast the nature of a bug versus a design flaw in the context of their capstone project, providing specific examples.
4. Critique the effectiveness of their own testing strategies based on the outcomes of user acceptance testing and suggest revisions.
5. Synthesize user feedback into actionable changes for their capstone project, demonstrating an iterative development process.

Peer Teaching

⏱ 45 min·Pairs

Pair Testing: Unit Test Challenges

Pairs select functions from their capstone code and write 5-10 unit tests, including edge cases like null inputs. They run tests using frameworks like JUnit or pytest, then swap code with another pair for verification. Discuss failures and refactor as needed.

Prepare & details

How do we prove that our code works as intended under edge-case conditions?

Facilitation Tip: During Pair Testing, assign roles explicitly so one student writes tests while the other implements the function, forcing both to think critically about the other’s work.

Setup: Presentation area at front, or multiple teaching stations

Materials: Topic assignment cards, Lesson planning template, Peer feedback form, Visual aid supplies

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

Peer Teaching

⏱ 35 min·Small Groups

Small Group: Edge Case Brainstorm

Groups list 20 potential edge cases for a shared app feature, such as maximum data limits or network failures. They code and run tests for the top 5. Present results to the class, highlighting unexpected bugs.

Prepare & details

What is the difference between a bug and a design flaw?

Facilitation Tip: In Edge Case Brainstorm, provide a checklist of common failure points (e.g., null inputs, max values) to guide groups without giving away answers.

Setup: Presentation area at front, or multiple teaching stations

Materials: Topic assignment cards, Lesson planning template, Peer feedback form, Visual aid supplies

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

Peer Teaching

⏱ 50 min·Whole Class

Whole Class: User Acceptance Simulation

Students role-play users with scripted tasks on peers' capstone apps. Log usability issues on shared forms. Debrief as a class to prioritize fixes based on feedback frequency.

Prepare & details

How does user feedback change the trajectory of a software project?

Facilitation Tip: For User Acceptance Simulation, give students scripted but ambiguous user feedback to practice distinguishing between bugs and design gaps.

Setup: Presentation area at front, or multiple teaching stations

Materials: Topic assignment cards, Lesson planning template, Peer feedback form, Visual aid supplies

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

Peer Teaching

⏱ 30 min·Individual

Individual: Bug Hunt Refactor

Each student introduces deliberate bugs into sample code, then writes tests to detect them. Refactor the code to pass all tests. Submit test suites with coverage reports.

Prepare & details

How do we prove that our code works as intended under edge-case conditions?

Facilitation Tip: During Bug Hunt Refactor, require students to document each bug they find with a reproducible test case before attempting fixes.

Setup: Presentation area at front, or multiple teaching stations

Materials: Topic assignment cards, Lesson planning template, Peer feedback form, Visual aid supplies

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

Teaching This Topic

Experienced teachers approach this topic by treating testing as a design activity, not an afterthought. They avoid lectures on tools by embedding testing into every coding task, so students see it as part of the process, not a separate phase. Research shows that early and frequent testing reduces frustration later, so teachers model iterative cycles where students write tests, run them, and refine both code and tests together. Avoid letting students skip edge cases or treat testing as optional—these habits are hard to unlearn.

What to Expect

Successful learning looks like students confidently designing tests that cover normal cases, edge conditions, and user scenarios before writing final code. They should articulate why certain tests matter and adjust their approach based on peer feedback or simulation results. Ultimately, they move from seeing testing as a chore to viewing it as a critical design tool.

Watch Out for These Misconceptions

Common Misconception

During Pair Testing, watch for students who only test happy paths or obvious cases.

What to Teach Instead

Prompt pairs to take turns acting as a skeptical user who tries to break the code, using the provided checklist to generate edge cases like empty strings or extreme values.

Common Misconception

During Edge Case Brainstorm, watch for students who assume edge cases are rare and therefore unimportant.

What to Teach Instead

Ask groups to estimate the likelihood of each edge case in real-world use and prioritize tests based on impact, using their brainstormed list as a starting point.

Common Misconception

During User Acceptance Simulation, watch for students who dismiss user feedback as irrelevant or blame the user.

What to Teach Instead

Use the simulation debrief to tie feedback directly to requirements, asking students to revise their testing plans to include scenarios where user expectations weren’t met.

Assessment Ideas

Quick Check

After Pair Testing, collect each pair’s written test cases and evaluate them for coverage of edge conditions and clear failure messages.

Discussion Prompt

During Edge Case Brainstorm, circulate and listen for groups that articulate why certain edge cases matter to the end user, then call on them to share their reasoning with the class.

Peer Assessment

After Bug Hunt Refactor, have students swap their revised testing plans and use a rubric to assess whether peers included tests for edge cases and user scenarios described in the simulation.

Extensions & Scaffolding

• Challenge students to design a testing strategy for a hypothetical third-party API integration, including tests for rate limits, malformed responses, and unexpected failures.
• Scaffolding: Provide a partially written test suite with missing assertions or edge cases for students to complete before pairing with a peer.
• Deeper exploration: Have students research industry standards (e.g., ISO 25010) and revise their capstone testing plans to align with a specific quality model.

Key Vocabulary

Unit Testing	A software testing method where individual units or components of software are tested to determine if they are fit for use. This focuses on verifying that each part of the code works correctly in isolation.
User Acceptance Testing (UAT)	The final stage of software testing where the software is tested by the end-user or client to verify that it meets business requirements and user needs before deployment.
Bug	An error, flaw, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
Design Flaw	An issue stemming from the initial planning or architecture of a software system, where the intended functionality or user experience is fundamentally problematic or incomplete.
Test Case	A set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly. This includes expected outcomes.