Testing and evaluating solutions

Introduction to Testing and Evaluating Solutions

Imagine you have spent hours building a complex Lego castle. Before you show it off, you probably press down on the towers to make sure they don't fall over and check if the drawbridge actually opens. In Computer Science, we do the exact same thing! Testing and evaluating is the final, vital stage of the computational thinking process. It is where we check if our solution actually works, if it meets the needs of the user, and how we can make it even better.

Don't worry if this seems like a lot of work after you’ve already "finished" coding. Think of it as the safety net that catches errors before they become "real-world" problems. In this chapter, we will learn how to strategically break our programs so we can fix them!

The Goal of Testing

Testing isn't just about finding "bugs" (errors). It is a systematic process to ensure that the solution performs exactly as intended. In the context of B.1 Computational thinking, we test to:

• Verify that the program produces the correct output for a given input.
• Ensure the solution handles unexpected situations without crashing.
• Confirm that we have met the success criteria we defined at the start of the project (as discussed in the "Specifying problems" chapter).

Types of Test Data

To test a solution thoroughly, we can't just type in random numbers. We need a testing strategy. We use three specific types of data to make sure every corner of our code is checked:

1. Normal Data

This is "expected" data. If a program asks for a user's age between 1 and 100, entering 25 is normal data. It is data that is clearly within the limits and should be processed without any issues.

2. Extreme (Boundary) Data

Errors often happen at the very edges of what is allowed. Extreme data (also called boundary data) sits at the absolute limits of the acceptable range. For our age example (1 to 100), the extreme data would be 1 and 100. Testing these ensures the program doesn't accidentally exclude the very first or last valid options.

3. Abnormal (Invalid) Data

This is data that the program should not accept. What happens if the user types -5, 150, or the word "Banana"? Abnormal data tests whether your program can handle "garbage" input gracefully (e.g., by showing an error message) instead of crashing.

Quick Tip: On an exam, if you are asked to provide a test plan, always include at least one example of Normal, Extreme, and Abnormal data!

Trace Tables: Testing the Logic

Sometimes we need to test our algorithmic thinking before we even touch a computer. We do this using a trace table (or a "dry run").

A trace table is a manual technique where you write down the values of variables on a piece of paper and update them line-by-line as you follow the logic of the algorithm. It helps you find "logical errors"—cases where the program runs but gives the wrong answer, like \(2 + 2 = 5\).

Example Trace Table logic:
If you have a loop: \(Count = Count + 1\), your table would look like this:

• Iteration 1: \(Count = 1\)
• Iteration 2: \(Count = 2\)
• Iteration 3: \(Count = 3\)

Evaluating the Solution

Once testing is finished, we move to evaluation. While testing asks "Does it work?", evaluation asks "How well does it solve the original problem?"

We evaluate the solution against the following factors:

• Success Criteria: Did we actually do what we set out to do? If the goal was to "calculate taxes automatically," does the program do that for all tax brackets?
• Efficiency: Does the solution run quickly, or does it make the computer lag? Does it use a huge amount of memory? (We want our solutions to be "lean and mean").
• Usability: Is it easy for a human to use? A perfect algorithm is useless if a person can't figure out which button to click.
• Constraints: Did the solution stay within the original limits? This could include things like budget, time, or specific hardware requirements.

Did you know?

In the real world, developers often use Alpha Testing (internal testing by the developers themselves) and Beta Testing (releasing the version to a small group of real users) to get feedback before the final release. This is all part of the evaluation process!

Improving the Solution

The computational thinking process is iterative. This means it is a loop! Based on our evaluation, we often find ways to improve the solution. This might involve:

• Refining the code: Making it shorter or faster.
• Fixing bugs: Solving the issues found during the testing phase.
• Adding features: Based on user feedback during evaluation.

Don't be discouraged if your first evaluation shows problems. The best software in the world—like your favorite video games or apps—went through thousands of versions and improvements!

Key Takeaways for Revision

• Testing is about checking for errors and correctness using Normal, Extreme, and Abnormal data.
• Trace tables are used to manually check the logic of an algorithm step-by-step.
• Evaluation is comparing the final solution against the original success criteria and user needs.
• The process is iterative: test, evaluate, improve, and repeat!

Note: This concludes the B.1 Computational Thinking section. Remember that these four stages—Specifying, Decomposing, Abstracting, and Testing—work together to solve complex real-world problems.