Show understanding of the need for a test strategy and test plan and their likely contents

12.3 Program Testing and Maintenance

Learning Objective

Show understanding of the need for a test strategy and a test plan, and describe their likely contents.

1. Why a Test Strategy Is Needed

• Provides a high‑level, project‑wide description of how testing will achieve the quality objectives (AO1).
• Ensures testing is:
  • Systematic and repeatable
  • Aligned with time, cost and resource constraints
  • Focused on the most critical risks (AO2)
  • Consistent across all development teams
• Prevents ad‑hoc testing that can miss defects, waste effort and reduce confidence in the final product.

2. Typical Contents of a Test Strategy (high‑level)

3. Why a Test Plan Is Needed

The test plan translates the high‑level strategy into a concrete, actionable document for the testing team. It tells how, when and by whom the testing will be carried out, ensuring that:

• All required test cases are created, reviewed and executed.
• Test data, environments and tools are prepared in advance.
• Progress can be measured against defined milestones.
• Stakeholders have clear visibility of testing activities and outcomes.

4. Typical Contents of a Test Plan (detail for implementation)

5. Key Testing Concepts Required by the Cambridge Syllabus

5.1 Types of Testing (AO2)

• Unit testing – tests individual functions or methods.
• Integration testing – tests interaction between modules.
• System testing – tests the complete, integrated system.
• Acceptance testing – verifies that the system meets user requirements.
• Regression testing – re‑runs selected tests after changes to ensure no new defects.
• Static analysis – reviews code without execution (e.g., linting, code walkthroughs).

5.2 Test‑design Techniques (AO2)

5.3 Test‑Driven Development (TDD) (AO3)

• Write a failing test case before any code.
• Write the minimum code to pass the test.
• Refactor the code while keeping the test green.
• Repeats for each new feature – encourages early detection of defects.

5.4 Defect Life‑Cycle (AO3)

1. Defect identified (during testing).
2. Defect recorded in a defect tracker.
3. Defect classified (severity, priority).
4. Defect assigned to a developer.
5. Defect fixed and code checked in.
6. Defect re‑tested (regression test).
7. Defect closed if the fix is successful.

6. Relationship Between Strategy and Plan

Test Strategy answers what and why – it sets the overall direction and quality goals. Test Plan answers how, when and by whom – it provides the detailed roadmap for execution. Alignment of the two ensures testing is both comprehensive and efficient.

7. Example: Testing a Simple Sorting Routine

7.1 Strategy Excerpt

• Scope: Sort routine and its public interface.
• Testing Levels: Unit (sorting function), Integration (sorting module with I/O handling).
• Testing Types: Functional (correct ordering) and non‑functional (performance on large arrays).
• Design Techniques: Black‑box (equivalence partitioning of input size), White‑box (100 % statement coverage).
• Risk: Incorrect handling of duplicate values, empty array, and boundary conditions.

7.2 Plan Excerpt (selected sections)

8. Test‑Case Structure (for reference)

9. Suggested Diagram

10. Mapping to Cambridge Assessment Objectives

11. Key Take‑aways

• Test strategy = overarching vision (what & why).
  Test plan = detailed roadmap (how, when, who).
• Both documents must be reviewed and updated as the project evolves.
• Clear entry and exit criteria prevent premature testing or endless cycles.
• Metrics gathered from the test plan help assess quality, inform decisions and guide future improvements.
• Linking strategy, plan and concrete test cases (as in the sorting‑algorithm example) demonstrates the full testing cycle required by the Cambridge syllabus.

Note: This note focuses on the testing unit (12.3) of the Cambridge AS & A‑Level Computer Science (9618) syllabus. Other units (e.g., Data Representation, Networks, Security, AI, Databases) are covered in separate lecture notes.