Unit 2: Digital Authoring Concepts – Significance of Testing & Developing Test Plans
Welcome to this study guide on Testing and Test Plans! Have you ever downloaded an app only for it to crash immediately, or played a video game where your character fell through the floor? Things like this happen when software is not tested properly.
In this chapter, you will discover why testing is an essential part of digital authoring, how developers plan their testing systematically, and how to select the exact data needed to prove that a digital solution works as intended. Don't worry if some of this seems technical at first — we will break everything down step-by-step with simple everyday examples!
---1. Why is Testing So Important? (The Significance of Testing)
Imagine building a brand-new rollercoaster. Would you let passengers ride it without testing the brakes, tracks, and safety bars first? Of course not! The same rule applies to digital authoring.
Testing is the process of running a digital system or program to find errors, check that it functions correctly, and ensure it meets all the user's requirements.
Here is why testing matters so much:
• To identify bugs and errors: Testing catches faults before the software is released to the public or the client.
• To ensure it meets user requirements: It confirms that the system actually does what the client asked for in the original design specification.
• To guarantee reliability and robustness: A robust program handles unexpected actions without crashing.
• To save time and money: Fixing a bug during development is much cheaper and easier than fixing it after thousands of customers have already installed it.
• To protect security: Testing helps uncover security loopholes that hackers could exploit.
Did you know? In 1996, the Ariane 5 rocket exploded just 37 seconds after launch because of a software bug that was never caught during testing. That tiny bug cost roughly \$370 million!
Key Takeaway
Testing is not something you do just at the very end to show off your work; it is a vital safety net that ensures software is accurate, functional, secure, and reliable.
---2. When Does Testing Take Place?
Testing is not a one-off event. In modern digital authoring, testing happens in stages throughout the entire development lifecycle.
A. Iterative Testing
Iterative testing means testing small parts or modules of a program while it is being built. Developers write a small piece of code, test it immediately, fix any bugs, and then move on to the next part.
Analogy: When baking a soup, you taste it periodically along the way to check the seasoning, rather than waiting until the entire dinner is served.
B. Final (Summative) Testing
Final testing occurs right at the end of the development process, once all the separate parts are joined together. It checks whether the complete system functions properly as a whole and meets all initial project requirements.
Analogy: This is the final test drive of a car after all the individual parts (engine, wheels, electrical systems) have been assembled in the factory.
Key Takeaway
Iterative testing happens during creation to catch small bugs early. Final testing happens at the end to ensure the complete product works as expected.
---3. What is a Test Plan?
Testing cannot be done randomly. If you simply click random buttons and type whatever comes to mind, you will miss hidden bugs. Instead, developers create a Test Plan.
A Test Plan is a structured document that details what will be tested, how it will be tested, the data that will be used, and the results that are expected.
Essential Columns in a Test Plan
When you design a test plan in an exam or project, it is usually laid out as a table with the following parts:
1. Test Number / ID: A unique number (e.g., Test 1, Test 2) to keep tests organized.
2. Test Description (Purpose): A clear explanation of what specific feature or rule is being checked (e.g., "Check that passwords must be at least 8 characters long").
3. Type of Test Data: Whether the data is Normal, Boundary, or Erroneous (we will cover these next!).
4. Test Data: The exact values typed into the system (e.g., "Secret12").
5. Expected Result: What the computer should do if everything is working correctly (e.g., "Password accepted, user proceeds to homepage").
6. Actual Result: What the computer actually did when the test was run (e.g., "Password accepted" or "Error: Screen froze").
7. Remedial Action / Status: What needs to be fixed if the test failed, or marked as 'Pass' if it worked.
Key Takeaway
A test plan prevents guesswork by providing a clear, repeatable roadmap of every test, showing what goes in and what should come out.
---4. The Three Types of Test Data
To test a system thoroughly, you must feed it different types of data. In your CCEA exams, you must know and be able to select these three types of test data:
1. Normal (Valid) Data
• What it is: Data that is typical, sensible, and falls well within the expected limits.
• What should happen: The system should accept it without any errors.
• Example: If an input box asks for a month of the year as a number from \(1\) to \(12\), entering \(5\) (May) or \(8\) (August) is Normal Data.
2. Boundary (Extreme) Data
• What it is: Data that sits right on the outer edges or limits of what is acceptable.
• What should happen: The system should accept it, because it is still valid, but it tests the exact changeover points.
• Example: For a range of \(1\) to \(12\), the Boundary Data values are \(1\) (the minimum allowed) and \(12\) (the maximum allowed).
3. Erroneous (Invalid) Data
• What it is: Data that is completely unacceptable, outside the allowed range, or of the wrong data type.
• What should happen: The system should reject the data and display a helpful error message without crashing.
• Example: For a range of \(1\) to \(12\), entering \(0\), \(13\), \(-4\), or typing the word "Seven" are all Erroneous Data.
Memory Trick: "No Bugs Ever"
To remember the three test data types, remember the letters N - B - E:
• N = Normal (Standard, valid data)
• B = Boundary (The outer edges)
• E = Erroneous (Invalid / incorrect data)
Key Takeaway
Thorough testing always includes Normal data (to check it works under regular conditions), Boundary data (to check the extreme limits), and Erroneous data (to check error handling).
---5. Worked Example: Designing Test Data
Let’s put this into practice with a realistic exam-style scenario.
Scenario: A school cinema booking system allows students aged between \(11\) and \(18\) inclusive to purchase a ticket (\(11 \le \text{Age} \le 18\)).
Let's look at how we select our test data:
• Normal Test: Data = \(14\).
Expected Result: Accepted. Ticket issued.
• Boundary (Lower Limit) Test: Data = \(11\).
Expected Result: Accepted. Ticket issued.
• Boundary (Upper Limit) Test: Data = \(18\).
Expected Result: Accepted. Ticket issued.
• Erroneous (Too Low) Test: Data = \(10\).
Expected Result: Rejected. Error message: "You must be at least 11 years old."
• Erroneous (Too High) Test: Data = \(19\).
Expected Result: Rejected. Error message: "Age exceeds maximum limit."
• Erroneous (Wrong Data Type) Test: Data = "Twelve".
Expected Result: Rejected. Error message: "Please enter numbers only."
6. Types of Errors Caught During Testing
When executing your test plan, you will encounter different types of errors. Here are the three main types to understand:
1. Syntax Errors
These are mistakes in the grammar or spelling rules of the programming language. The computer does not understand the instruction at all.
• Example: Typing PRNT("Hello") instead of PRINT("Hello").
2. Logic Errors
The code runs without crashing, but it produces the wrong output because the developer made a mistake in the logic or calculation.
• Example: Writing \(\text{Area} = \text{Length} + \text{Width}\) instead of \(\text{Area} = \text{Length} \times \text{Width}\). The computer calculates a number, but the answer is mathematically wrong!
3. Runtime Errors
An error that happens while the program is running, causing it to freeze or crash unexpectedly. This usually happens when the computer is asked to do something impossible.
• Example: Asking the computer to divide a number by zero (e.g., \(100 \div 0\)), or looking for a file that does not exist on the hard drive.
Key Takeaway
Syntax = broken grammar rules (won't start).
Logic = wrong calculation/thinking (gives wrong answer).
Runtime = impossible instruction (crashes mid-run).
7. Common Mistakes to Avoid in the Exam
• Vague Expected Results: Never just write "It works" or "Error" in a test plan. Always be precise: "User is redirected to the home screen" or "An error message appears stating 'Enter a valid email'".
• Confusing Boundary and Erroneous Data: For a range of \(1\) to \(100\), remember that \(1\) and \(100\) are Boundary (valid), while \(0\) and \(101\) are Erroneous (invalid).
• Only Testing Valid Data: A common student mistake is only testing data that works. You must always test invalid (erroneous) data to prove the program doesn't crash!
Quick Summary Review
• Testing ensures a digital solution meets requirements, is bug-free, secure, and robust.
• Iterative testing is carried out during authoring; Final testing is completed at the end.
• A Test Plan contains: Test ID, Description, Data Type, Test Data, Expected Result, Actual Result, and Remedial Action.
• Normal Data: Expected, typical valid values.
• Boundary Data: Valid values on the extreme edges of allowed ranges.
• Erroneous Data: Invalid values that should be rejected with an appropriate error message.