Know and understand the definition, characteristics and use of test data using normal, abnormal and extreme data

7 The Systems Life Cycle (SLC)

Objective

Know and understand the whole SLC – analysis, design, development & testing, implementation, documentation and evaluation – and be able to define, select and use normal, abnormal and extreme test data effectively.

7.1 Analysis

The aim of analysis is to produce a clear, written description of the current system and the requirements for the new system.

• Techniques for gathering information

  • Observation – watch users perform tasks.
  • Interviews – ask open‑ended questions.
  • Questionnaires – collect data from many users quickly.
  • Document review – study existing forms, reports, manuals.

• System specification template (syllabus requirement)

  System Specification
  Purpose	What the system will achieve.
  User requirements	Functions users need (e.g., calculate payroll).
  Information requirements	Data that must be stored, processed and reported.
  Inputs	All data entered by users or other systems.
  Outputs	Reports, screens, printed documents.
  Constraints	Hardware, software, legal or security limits.

7.2 Design

Design converts the specification into detailed artefacts that guide development and testing.

• Data & file structures

  • Data dictionary – defines each field (name, type, length, allowed values, mandatory). See the example in the next box.
  • File‑layout diagram – shows the physical record format and the relationship between files. (A simple block diagram is sufficient for IGCSE.)

• Input & output formats

  • Screen/form mock‑ups with labelled fields.
  • Report templates (column headings, totals, footers).

• Validation routines (the basis for test data)

  • Range checks – value must be between a minimum and maximum.
  • Type checks – numeric, alphabetic, date, etc.
  • Format checks – e.g., “DD/MM/YYYY”.
  • Presence checks – mandatory fields cannot be blank.
  • Check‑digit or checksum rules for IDs.

Example: Data Dictionary for a Payroll System

Simple File‑Layout Diagram (illustrative)

+-------------------+-------------------+-------------------+
| Record 1 (Employee)                              |
|---------------------------------------------------|
| EmpID (6) | Name (30) | Salary (7) | DOB (10)   |
+-------------------+-------------------+-------------------+
| Record 2 (Employee) …………………………………………|
+---------------------------------------------------+

7.3 Development & Testing

7.3.1 Development

Write the program, create the database or configure the off‑the‑shelf package according to the design artefacts. Follow good coding practice – naming conventions, comments and modular structure – to make later testing easier.

7.3.2 Testing strategy

• Module (unit) testing – test individual routines or screens.
• Integration testing – test interaction between modules (e.g., data entry → calculation).
• System testing – test the complete solution against the original specification.

7.3.3 Test‑Plan Checklist (AO3 requirement)

7.3.4 Test Data – Normal, Abnormal & Extreme

Why each type is needed (AO3 analysis)

• Normal data – demonstrate that the system does what it should for the majority of users.
• Abnormal data – test the robustness of validation routines – essential for security and data integrity.
• Extreme data – apply the principle of boundary‑value analysis, which uncovers the highest proportion of input‑related bugs.

Security & confidentiality of test data

• Mask or anonymise personal data (use fictitious names, dummy account numbers).
• Store test data in a protected folder with read‑only rights for testers.
• Delete or overwrite test files after the testing phase to avoid accidental release of sensitive information.

7.4 Implementation

Implementation moves the tested solution into the live environment. Four common strategies are used, each with advantages and disadvantages.

Simple decision‑matrix (example)

7.5 Documentation

Good documentation supports users, maintainers and future developers. Two families are required by the syllabus.

Technical documentation (for developers/maintainers)

• System overview and architecture diagram.
• Data dictionary and file‑layout diagram.
• Source‑code listings (or module descriptions) with comments.
• Installation and configuration instructions.
• Test‑plan and test‑case results (useful for regression testing).

User documentation (for end‑users)

• Purpose of the system and any prerequisites.
• Step‑by‑step procedures (e.g., “How to enter a new employee”).
• Screen mock‑ups with labelled fields.
• Examples of correct and incorrect input.
• Troubleshooting guide and contact details for support.

Audience awareness

Tailor language, level of detail and visual aids to the intended audience – technical staff need precise terminology, whereas non‑technical staff benefit from screenshots and plain‑English instructions.

7.6 Evaluation

After implementation the solution is reviewed against the original requirements and the six evaluation criteria set out in the syllabus.

Document the findings, suggest improvements and, if necessary, plan a new iteration of the SLC (often called a “maintenance cycle”).

Glossary (AO1 – recall)

• Normal test data – values that lie comfortably within the defined valid range; used to confirm that the system works as intended under typical conditions.
• Abnormal test data – values that violate one or more validation rules (wrong type, out‑of‑range, missing mandatory field); used to check error handling.
• Extreme test data – values that sit on or just beyond the boundaries of the valid range; used for boundary‑value analysis.
• Boundary‑value analysis – a testing technique that focuses on the limits of input domains because many defects occur at the edges.
• Data dictionary – a table that defines each data item (field name, type, length, valid values, mandatory status).
• File‑layout diagram – a visual representation of the physical structure of a file or database table.

Key Points to Remember

• The SLC consists of Analysis → Design → Development & Testing → Implementation → Documentation → Evaluation.
• Good test data are relevant, representative, traceable, repeatable and clearly documented.
• Use normal, abnormal and extreme data to verify functionality, error handling and boundary conditions.
• Prepare a concise test‑plan checklist before execution – it links test objectives, cases, data, expected results and pass/fail criteria.
• Choose an implementation method that balances cost, risk and training needs.
• Produce both technical and user documentation, keeping the audience in mind.
• Evaluate the final system against functional, efficiency, usability, security & data protection, reliability & maintainability, and legal & ethical criteria; record improvements for future cycles.