Development and Testing: Making Sure Our ICT System Actually Works! (Syllabus Section 7.3)

Hello future ICT experts! Welcome to the most important stage of the Systems Life Cycle: Development and Testing. Think of system development like baking a complicated cake. Analysis is choosing the ingredients, Design is writing the recipe, and Development is actually baking it.

But before you serve that cake (implementation), you need to TASTE it (testing)! Is it cooked through? Does it taste right? Does it fall apart? In ICT, testing is where we find and fix all the errors (bugs) before the system is used by real people. Let's dive into how we make our ICT systems strong, reliable, and error-free.

1. The Essential Need for Testing

Why do we bother testing? The syllabus states clearly that there is a need to test the system before implementation.

Why Testing is Non-Negotiable:

  • Catching Errors (Bugs): All programs have errors. Testing finds these faults before they cause serious problems for the users or the organisation.
  • Ensuring Requirements are Met: Testing confirms that the new system does exactly what the client originally asked for during the Analysis stage.
  • System Reliability: A well-tested system is less likely to crash or produce incorrect data when it goes live.
  • User Confidence: If the system works perfectly from day one, users will trust it immediately.

Did you know? A software bug that caused the $370 million failure of the Ariane 5 rocket in 1996 was traced back to an unhandled data conversion error in software that was not tested with extreme data. Always test!

Quick Review: The Goal of Testing

The main goal is simple: ensure the actual outcomes produced by the system match the expected outcomes defined in the design phase. If they don't match, we fix the fault!

2. Testing Strategies and Scope

You can't test everything at once. The syllabus specifies three key levels of Test Strategies:

Testing Each Module (Unit Testing)

This involves testing each individual part, component, or "module" of the system in isolation.

  • What is a module? A distinct block of code or sub-system, such as a database table structure, a single form, or a calculation sub-routine.
  • Advantage: It is much easier to isolate and locate the exact source of a bug when dealing with a small section of code.

Analogy: If you are building a LEGO castle, module testing is making sure each individual wall segment is correctly assembled before joining them all together.

Testing Each Function

This strategy checks every specific feature or functional operation within the system to ensure it performs its intended job accurately.

  • What is a function? A specific task or operational capability, such as searching for a customer record, calculating total sales tax, printing a receipt, or validating a password.
  • Purpose: Verifies that every separate requirement specified by the client produces the expected output when triggered.

Testing the Whole System (Integration Testing)

Once all modules and individual functions work properly on their own, we test how the entire system operates together.

  • This confirms that data flows correctly from one module and function to the next (e.g., an input form successfully passes entered details into the database structure and generates a summary report).
  • This provides comprehensive testing, ensuring all parts function together as a unified system under real-world conditions.

Key Takeaway: Test strategy progression: test each module → test each function → test the whole system.

3. Designing the Test Plan

A Test Plan is a formal document that details every single test that will be run. It ensures testing is structured, complete, and provides clear steps for remedial action (fixing the problem).

Components of a Good Test Plan:

For every test case, you must define four key elements:

  1. Test Data: The data (inputs) that you will feed into the system.
  2. Expected Outcomes: What the system should produce. This is calculated manually or predicted beforehand.
  3. Actual Outcomes: What the system actually produces when the test data is input.
  4. Remedial Action Following Testing: The action taken if the Actual Outcome does not match the Expected Outcome (e.g., "Adjust validation routine" or "Check file structure definition").

Memory Aid: Think of a test plan as a T.E.A.R. sheet: Test Data, Expected Outcome, Actual Outcome, Remedial Action.

4. Types of Test Data: Finding the Limits

To properly check a system, especially its validation routines, we must use different types of data.

4.1 Normal Data

Characteristics: Data that is valid, expected, and within the specified acceptable limits (range).

Use: To check that the system processes standard, correct input accurately.

Example: If a form asks for age between 16 and 60, Normal Data would be 35.

4.2 Extreme Data (Boundary Data)

Characteristics: Data that is valid but is exactly at the upper or lower limits (boundaries) of the acceptable range.

Use: To ensure the system correctly handles the boundaries. Programmers often make boundary comparison errors (e.g., using < instead of <=). Extreme data catches this.

Example: If the age range is 16 to 60, Extreme Data would be 16 and 60.

4.3 Abnormal Data (Invalid Data)

Characteristics: Data that is invalid and should be rejected by the system's validation checks. This includes data outside the range, wrong data types, or incorrect formats.

Use: To test the robustness of the system's validation routines and error messages. We test whether the system prevents bad data from being entered.

Examples:

  • Out of range: Age 5 or Age 75.
  • Wrong type: Entering the word "Thirty-Five" into a numeric age field.
  • Too short/long: Entering only two digits for a phone number that requires ten.
Common Mistake Alert!

Don't confuse Extreme Data (which is valid and accepted) with data just outside the boundary (which is abnormal and rejected).
If the range is 10 to 20:
• Normal: 15
• Extreme: 10, 20
• Abnormal: 9, 21, "cat"

4.4 The Use of Live Data

Towards the end of the testing phase, especially if migrating from an old system, you might use Live Data.

Definition: This is real data that has been used and processed by the existing (old) system.

Use: It provides a highly realistic test environment because it mimics the volume, variety, and complexity of the actual data the system will encounter when fully operational.

Caution: When using live data, you must ensure that the new system is run in a way that doesn't affect the running of the existing system or corrupt the real, valuable data. This often happens during Parallel Running (a type of implementation).

5. Testing Specific System Components

Your test plan must ensure that you specifically test the components designed during the design stage:

Testing Data Structures and File Structures

This ensures database tables and file structures are correctly set up. You must check:

  • Are the field lengths appropriate (e.g., is the name field long enough)?
  • Are the data types correct (e.g., is "Price" set as numeric/currency rather than text)?
  • Are the Primary and Foreign Keys working to maintain relationships between tables?

Testing Input and Output Formats

This checks the user interface and reporting formats:

  • Input Formats: Check that data capture forms and screens are intuitive, easy to navigate, and capture all necessary data accurately.
  • Output Formats: Check that reports, screen layouts, and printed documents display correct values, use appropriate headings, and are properly formatted and aligned.

Testing Validation Routines

Systematically verify that all programmed validation rules catch invalid inputs:

  • Range Check: Ensures data falls within specified numerical or date boundaries.
  • Type / Character Check: Ensures data contains only allowable characters (e.g., digits only in a phone number).
  • Length Check: Ensures inputs have the exact or allowable number of characters.
  • Presence Check: Prevents key fields from being left blank.
  • Format Check: Confirms data conforms to a predetermined pattern (e.g., LLNN NLL for a postcode).
  • Check Digit: Verifies numerical codes (like barcodes or ISBNs) by recalculating the checksum.

Key Takeaway: Development and testing go hand-in-hand. You develop a piece, then test it thoroughly using normal, extreme, and abnormal data. A structured test plan is the roadmap to a successful, bug-free launch!