VCE Applied Computing: Data Analytics (Year 12) · Software Development crossover (not Data Analytics key knowledge) · 18m read

Software Development — Validation, Testing and the SRS

Crossover note: validation and testing apply to Data Analytics too, but the SRS is Software Development content (a separate Units 3–4 study with its own subject on VCE Vault). Working code is not enough — it has to be specified, validated and tested. The software requirements specification (SRS) and a good test plan are core parts of the Unit 3 and 4 SAT, and they turn up in the exam every year.

Learning objective: Write a software requirements specification, apply validation techniques and design test data.

By the end of this lesson you can:

• I can describe the contents of an SRS.
• I can apply existence, type and range checks.
• I can design valid, invalid and boundary test data.

Validation is a bouncer at the door. It checks every piece of data before it enters — right type, range and format — keeping bad data out.

Specify, validate, test

SOFTWARE REQUIREMENTS SPECIFICATION (SRS):
• Purpose and scope of the software.
• Functional and non-functional requirements.
• Constraints and assumptions.
• Characteristics of the users and operating environment.
• Often includes use case diagrams, context diagrams and data flow diagrams.

VALIDATION (checking input is reasonable):
• EXISTENCE check — a value has been entered.
• TYPE check — the value is the right data type.
• RANGE check — the value lies within allowed limits.
• Validation does NOT guarantee data is correct — only reasonable.

TESTING:
• Testing checks the solution does what it should.
• Use a TEST TABLE: test data, expected result, actual result.
• Choose test data that is VALID, INVALID and at the BOUNDARIES.
• Useability testing checks real users can operate it.

DEBUGGING:
• Syntax errors, runtime errors and logic errors.
• Logic errors produce wrong output without crashing — found by testing and tracing.

Quick reference

| Concept | Example |
|---|---|
| Existence check | Field not empty |
| Type check | Number not text |
| Range check | Age 0–120 |
| Test data | Valid, invalid, boundary |
| SRS | Software Requirements Specification |

Key ideas at a glance

• Validate input: Existence, type, range.
• Test with boundary data: Edges.
• Document tests: Testing tables.
• SRS guides development: Agreed requirements.

Worked example (Medium)

An input accepts a student age from 12 to 18 inclusive. Design test data.

1. Valid. 15 → accepted.
2. Boundaries. 12 and 18 → accepted; 11 and 19 → rejected.
3. Invalid type. "fifteen" → rejected by type check.
4. Existence. Blank → rejected by existence check.

Answer: Test 15, 12, 18, 11, 19, "fifteen" and blank, with expected results.

Common mistakes

• Confusing validation with verification Validation checks input is reasonable; verification checks it matches the source. Fix: Use the right term for the right check.
• Only testing "normal" data Errors cluster at boundaries. Fix: Always include boundary and just-outside values.

The Mars Climate Orbiter

In 1999 NASA lost the Mars Climate Orbiter because one team used imperial units and another metric. The data wasn't validated for units.

Validation and testing prevent costly failures.

Practice questions

1. A program outputs the wrong total but does not crash. This is most likely a:

   1. Syntax error
   2. Runtime error
   3. Logic error
   4. Validation error

   (1 marks)

Summary

• The SRS captures requirements, constraints, users and environment.
• Existence, type and range checks validate input.
• Test valid, invalid and boundary data.