Know and understand test strategies including to test each module, each function and the whole system

7. The Systems Life Cycle – Test Strategies

Objective

Students will be able to know and understand test strategies, including how to test each module, each function and the whole system. They will also see how testing fits with the other stages of the Systems Life Cycle (analysis, design, development, implementation and maintenance) and how it links to the Cambridge assessment objectives:

• AO1 – Knowledge and understanding: terminology such as functional/non‑functional requirements, unit testing, regression testing, etc.
• AO2 – Application: selecting appropriate test techniques, preparing test data, choosing an implementation method.
• AO3 – Analysis and evaluation: linking test results to requirements, evaluating the chosen implementation method and suggesting improvements.

7.1 Analysis

The analysis stage records the current system, identifies user requirements and produces a requirements specification document (a compulsory artefact for AO3).

Types of requirements

• Functional requirements – what the system must do (e.g. “record each pupil’s attendance”).
• Non‑functional requirements – how the system must perform (e.g. “response time < 2 seconds”, “data stored securely”).

Typical research techniques (school‑attendance example)

Output of analysis

• Requirements specification (functional & non‑functional).
• Initial data‑flow diagram (high‑level).
• List of constraints (hardware, legal, budget).

7.2 Design

Design converts the analysed requirements into concrete data structures, input/output formats, file structures and validation routines.

Data‑flow example – Student‑record system

[User] → (Enter Student Details) → [Validation] → (Store in Database) → (Generate Report) → [User]

Sample data‑structure table

Validation routine (range‑check for grades)

IF Grade >= 0 AND Grade <= 100 THEN
Accept value
ELSE
Display “Grade must be between 0 and 100”
END IF

Input / output format design (relevant to Sections 11‑16)

• Screen‑form layout – field labels, tab order, mandatory indicators.
• File format – e.g., CSV file with headings StudentID,FirstName,LastName,Grade,Attendance, UTF‑8 encoding.
• Presentation output – report template (header, footer, page‑breaks) to be opened in a word‑processor.

7.3 Development & Testing

Test plan – one‑page template

Test data – normal, abnormal and extreme cases (login form example)

Levels of testing

Designing effective test cases

Each test case should contain:

1. Test case ID
2. Reference requirement (link to the specification document)
3. Pre‑conditions
4. Test steps
5. Test data (including edge cases)
6. Expected result
7. Actual result (filled after execution)
8. Pass/Fail status

Common test techniques

• Black‑box testing – focus on inputs and expected outputs; internal code is not examined.
• White‑box (structural) testing – examine internal logic, paths, loops and conditions.
• Boundary‑value analysis – test values at the edges of input ranges.
• Equivalence partitioning – divide input data into equivalent classes to reduce the number of test cases.
• Decision‑table testing – useful for complex business rules.
• Usability testing – assess ease of navigation and screen layout (relevant to Section 12).
• File‑management testing – verify that a saved document opens correctly on another device, that data is not corrupted, and that file permissions are respected (Sections 11‑16).

Recording and reporting test results

Regression testing (maintenance phase)

Whenever a change is made (e.g., a new field added to the student record), re‑run a selected set of previously‑passed test cases on a copy of the live database to ensure existing functionality has not been broken.

7.4 Implementation

Four common implementation methods are used to move a tested system into live operation.

Post‑implementation activities

• Training – brief sessions for teachers, pupils and administrative staff.
• Documentation hand‑over – user manuals, help files, maintenance guides.
• Support and maintenance plan – schedule for backups, security updates and future enhancements.
• Review – collect user feedback and compare actual performance with the original non‑functional requirements.

7.5 Documentation

Documentation is a compulsory part of the SLC and is assessed under AO3.

7.6 Evaluation

Evaluation links the whole project back to the original objectives and assesses its success.

Linking testing to the Systems Life Cycle

1. Requirements analysis – define test criteria linked to each functional and non‑functional requirement.
2. Design – create test cases, choose techniques, produce data‑flow diagrams and validation rules.
3. Development – perform module (unit) testing as code is written.
4. Integration – carry out integration testing after each build.
5. System testing – execute full‑system functional, performance, security and usability tests.
6. Acceptance testing – obtain formal sign‑off from end‑users before go‑live.
7. Implementation – choose an implementation method; run final acceptance tests in the live environment.
8. Maintenance – run regression tests whenever changes are made and update documentation accordingly.

Key take‑aways

• Test early and often – unit testing catches defects before they propagate.
• Use both black‑box and white‑box techniques for thorough coverage.
• Document every test case, data set (normal, abnormal, extreme) and result; this provides evidence of quality and links back to the specification.
• Choose an implementation method that balances risk, cost and the school’s timetable, and plan post‑implementation training and support.
• Acceptance testing is the final checkpoint before the system goes live; a formal sign‑off is required.
• Evaluation must demonstrate how the system meets the original requirements and how the testing and implementation choices contributed to success.