Lesson Plan

• Describe the main types of software testing and their purposes.
• Explain black‑box, white‑box and grey‑box testing approaches.
• Apply test‑data selection techniques (equivalence partitioning, boundary value analysis, decision tables, state transition, use‑case) to choose appropriate inputs.
• Evaluate test coverage using statement, branch, and path metrics.
• Select suitable testing level and method for a given maintenance scenario.

• Projector or interactive whiteboard for slides.
• Printed handout summarising testing types and data‑selection techniques.
• Sample code (e.g., grade function) and IDE for live demonstration.
• Worksheets with test‑case design exercises.
• Sticky notes or cards for grouping test data.
• Access to a simple test‑management tool (optional) for documenting cases.

Begin with a quick poll: “When you run a program, how do you know it works?” Connect this to prior learning about the software development life‑cycle. Explain that today students will explore different testing methods and learn how to select appropriate test data, with success measured by correctly designing test cases for a sample function.

1. Do‑Now (5'): Students write one reason why testing is important on a sticky note and share with the class.
2. Mini‑lecture (15'): Overview of testing levels (unit, integration, system, acceptance) and approaches (black‑box, white‑box, grey‑box) using slides.
3. Interactive matching activity (10'): In small groups, match testing types to real‑world scenarios.
4. Data‑selection workshop (20'): Apply equivalence partitioning and boundary value analysis to the grade function; complete worksheet with test cases.
5. White‑box coverage demo (10'): Show statement and branch coverage in an IDE for a simple routine.
6. Consolidation quiz (5'): Kahoot/exit‑ticket with two short questions on selecting testing methods and data.

Recap how the chosen testing level and data‑selection technique ensure thorough verification of software behavior. Students complete an exit ticket naming one additional test case they would create for a new feature. For homework, they document a full set of test cases for a provided pseudo‑code module, citing the techniques used.