Unit 3: Digital Authoring Practice – Testing a Solution
Welcome to the study guide for Testing a Solution! Whenever you create a digital product—such as a database, an interactive multimedia presentation, a spreadsheet model, or a website—you need to make sure it actually works before handing it over to the user. Testing is the bridge between building something and knowing that it works reliably.
Don't worry if this topic feels technical at first! Testing is simply about playing detective, finding what is broken, and fixing it so your user has a smooth, error-free experience.
1. Why Do We Test?
Imagine buying a new mobile phone, turning it on, and discovering that the keyboard types the wrong letters or the battery percentage displays negative numbers. You would be frustrated! In digital authoring, testing ensures that products are fit for purpose.
We test our digital solutions to:
• Find and fix bugs or errors before the user encounters them.
• Check that all user requirements from the design stage have been fully met.
• Ensure the system is secure, reliable, and robust when handled roughly by users.
• Verify functionality, making sure calculations, links, buttons, and navigation work as planned.
• Save time and money, because fixing an error after release is far more difficult and expensive than fixing it during development.
Did You Know? In the software industry, finding and fixing a bug after releasing software can cost up to \(30\) times more than catching it during the testing stage!
Key Takeaway: Testing proves that a digital solution meets user needs, behaves correctly, and handles mistakes gracefully.
2. When Does Testing Happen?
Testing is not just a single step done at the very end. It happens at different stages of the development cycle:
A. Iterative (Ongoing / Formative) Testing
This is testing carried out during the creation of the solution. As you build each individual feature—like adding a formula in a spreadsheet or a navigation button on a web page—you test it immediately. If something breaks, you fix it right away before moving on to the next part.
B. Final (Summative) Testing
This is testing carried out at the very end once the complete solution is built. It tests the whole system working together against the original client requirements to make sure nothing has been missed.
C. User Acceptance Testing (UAT)
This involves giving the completed solution to the actual end users (or target audience) to try out. They check whether the solution is easy to use, visually appealing, and accomplishes the tasks they need.
Key Takeaway: Iterative testing happens as you build; final and user testing happen after you build.
3. Types of Test Data
To test a solution thoroughly, you cannot just type in whatever you feel like. You must test with specific categories of data to see how the system reacts.
Let’s imagine a digital form for a youth club that only accepts ages between 11 and 18 (inclusive: \(11 \le \text{Age} \le 18\)).
1. Normal (Valid) Data
• What it is: Data that is completely ordinary, sensible, and expected. It falls well within the allowed boundaries.
• Example: \(14\) or \(16\).
• Expected Result: The system should accept the data without any error.
2. Extreme (Boundary) Data
• What it is: Data at the outer edges or limits of what is acceptable.
• Example: \(11\) (the lowest allowed value) and \(18\) (the highest allowed value).
• Expected Result: The system should still accept this data, as it sits right on the allowed boundary.
3. Abnormal (Invalid / Erroneous) Data
• What it is: Data that is outside the allowed range or of the completely wrong data type.
• Example: \(9\) (too young), \(25\) (too old), or the word "Sixteen" (text entered into a numeric field).
• Expected Result: The system should reject the data and display a helpful error message.
4. Null (Empty) Data
• What it is: Leaving a required field completely blank to see if the system notices.
• Example: Clicking "Submit" without typing anything in the age box.
• Expected Result: The system should stop the user and indicate that the field is mandatory (a presence check).
Memory Trick: Think of the acronym N-E-A-N:
• Normal (Standard data)
• Extreme (Edge data)
• Abnormal (Incorrect data)
• Null (No data)
Key Takeaway: A complete test always tests what should work (Normal & Extreme) and what should not work (Abnormal & Null).
4. The Test Plan
A Test Plan is a structured document created before testing begins. It lists step-by-step everything that will be tested, what data will be used, and what result is expected.
Core Columns of a Standard Test Plan:
1. Test Number / ID: A unique reference for each test (e.g., Test 1, Test 2).
2. Test Description / Item to Test: What specific feature, calculation, or button is being checked.
3. Type of Test Data: Normal, Extreme, or Abnormal.
4. Test Data Used: The exact values entered into the system.
5. Expected Result: What should happen if the system works correctly.
6. Actual Result: What actually happened when the test was run.
7. Remedial Action (Action Taken): The fix or adjustment made if the actual result did not match the expected result.
Example Test Plan Row:
• Test ID: 04
• Item Tested: Student discount calculation (must be between \(5\%\) and \(20\%\))
• Type of Data: Abnormal
• Test Data: \(35\%\)
• Expected Result: Error message: "Discount must be between 5% and 20%"; value rejected.
• Actual Result: System accepted \(35\%\) and calculated an incorrect total.
• Remedial Action: Added a validation rule \((\text{Discount} \ge 0.05 \text{ AND } \text{Discount} \le 0.20)\) to the input cell.
Key Takeaway: A test plan proves your testing was systematic and shows how errors were corrected.
5. Types of Errors to Identify
When running tests, you are looking for three main types of errors:
1. Syntax Errors
• What they are: Mistakes in the grammar, spelling, or rules of the programming language or formula.
• Analogy: Writing an English sentence with terrible spelling and grammar so nobody can understand it.
• Example: Typing =SUMM(A1:A10) instead of =SUM(A1:A10) in a spreadsheet, or missing a closing bracket.
2. Logic Errors
• What they are: The program or formula runs without crashing, but it produces the wrong output because the underlying idea or calculation is incorrect.
• Analogy: Following a recipe correctly, but the recipe accidentally told you to add salt instead of sugar.
• Example: Typing Price + Discount instead of Price - Discount. The computer will happily do the addition, but the final price will be wrong!
3. Runtime Errors
• What they are: Errors that cause a program or script to crash while it is running, usually because it was asked to do something impossible.
• Example: Asking the computer to divide a number by zero \(\left(\frac{x}{0}\right)\) or trying to open a file that has been deleted or renamed.
Quick Review:
• Syntax: Broken rule / typo \(\rightarrow\) Cannot run.
• Logic: Flawed calculation \(\rightarrow\) Runs, but gives the wrong answer.
• Runtime: Impossible instruction \(\rightarrow\) Crashes during operation.
6. Validation and Verification
To prevent bad data from causing errors during testing, digital solutions use Validation and Verification. Students often mix these up, so let's keep the distinction simple!
A. Validation (Automated Computer Checks)
Validation is an automatic check performed by the computer to ensure that data entered is sensible, reasonable, and allowable.
Common Validation Checks:
• Range Check: Ensures a number is between an upper and lower limit (e.g., Exam mark between \(0\) and \(100\)).
• Presence Check: Ensures a field is not left blank (e.g., Surname is mandatory).
• Length Check: Checks that text contains an exact number of characters, or is within a set range (e.g., UK Postcode between \(6\) and \(8\) characters).
• Type Check (Data Type Check): Ensures the correct kind of data is entered (e.g., numbers only for telephone numbers).
• Format Check / Input Mask: Ensures data matches a preset pattern (e.g., Date as DD/MM/YYYY, or National Insurance number as LL NN NN NN L).
• Lookup Check: Checks data against an approved list of values (e.g., choosing a Title from a drop-down list: Mr, Mrs, Miss, Dr).
B. Verification (Checking Data Against the Source)
Verification is checking that data has been copied over accurately from the original source.
Common Verification Methods:
• Double Entry: Entering the same data twice (e.g., typing your new password twice when creating an account). The system checks that both entries match exactly.
• Visual Check / Proofreading: A person reads the screen and compares it manually with the original paper document to spot typos.
Important Distinction:
• Validation asks: "Is this data allowed by the rules?"
• Verification asks: "Does this data match the real-world source?"
Note: A name typed as "Jojhn" will pass validation (it contains only letters), but will fail verification because it does not match the actual name "John"!
7. Common Exam Mistakes to Avoid
• Confusing Extreme and Abnormal Data: Remember, extreme data is allowed (it is on the boundary). Abnormal data is not allowed.
• Vague Expected Results: Never write "it works" as an expected result. Always write specific details, such as "A pop-up message appears stating 'Invalid Date'" or "Total displays £45.00".
• Mixing up Logic and Syntax Errors: If a formula gives the wrong result but does not display a syntax alert, it is a logic error.
• Assuming Validation catches all mistakes: Validation only checks if data follows preset rules, not if it is actually true or accurate.
Chapter Summary Checklist
Before moving on, make sure you can:
• Explain why testing is essential in digital authoring.
• Distinguish between iterative (ongoing) testing and final testing.
• Identify and give examples of Normal, Extreme, and Abnormal test data.
• Describe the key parts of a Test Plan (ID, Description, Test Data, Expected Result, Actual Result, Remedial Action).
• Identify Syntax, Logic, and Runtime errors.
• Differentiate between Validation rules and Verification methods.