Evidence, testing and evaluation

Think of it like being a chef who bakes a delicious cake. Before you serve it to your friends, you'd taste it, right? You'd check if it's sweet enough, if it's cooked all the way through, and if it looks good. That's exactly what evidence, testing, and evaluation are for computer programs!

• Evidence: This is like taking notes while you're baking. You write down what ingredients you used, how long it baked, and what it tasted like. In computer science, it's about collecting information to show that your program works (or doesn't work) as expected. It's proof!
• Testing: This is like tasting your cake. You try different parts of it, maybe even give a slice to a friend to get their opinion. In computer science, you run your program with different inputs (like typing different things into a search bar) to see if it behaves correctly in all situations.
• Evaluation: After tasting and getting feedback, you decide if the cake is good enough to serve, or if it needs more sugar, less baking time, or a different frosting. In computer science, you look at all the evidence and test results to decide if your program meets all the requirements and if it's ready for people to use, or if it needs more work.

Let's imagine you're building a brand new calculator app for your phone. You want it to be super easy to use and always give the right answers.

1. Evidence Collection: As you build the app, you might write down how you designed the 'add' button, or why you chose certain colors. Later, when you test, you'll record the results. For example, you might write down: "When I typed '2 + 2', the app showed '4'." This is your evidence.
2. Testing: You wouldn't just assume it works! You'd try lots of different calculations:
   • Simple ones: 5 + 3, 10 - 7
   • Tricky ones: 0 / 5, 5 / 0 (this should show an error!), -2 * 4
   • Long ones: (10 + 5) * 2 - 3 You'd also check if the buttons are easy to press and if the numbers are clear to read. This is you actively testing your app.
3. Evaluation: After all that testing, you look at your evidence. Did 5 / 0 crash the app? (Bad!) Did 2 + 2 always give 4? (Good!) Did your friends find it easy to use? Based on all this, you evaluate if your calculator app is ready to be shared, or if you need to fix some bugs (errors) or make it more user-friendly.

Just like there are different ways to check if a cake is good (taste, smell, look), there are different ways to test software:

1. Functional Testing: This is like checking if the cake actually tastes good. Does the program do what it's supposed to do? Does the 'add' button on the calculator actually add numbers correctly?
2. Usability Testing: This is like checking if the cake is easy to eat (not too crumbly, easy to cut). Is the program easy for people to use? Can someone who has never seen your calculator app figure out how to use it right away?
3. Performance Testing: This is like checking if the cake bakes quickly enough or if it can feed a lot of people. Does the program run fast enough? Does it slow down if many people use it at the same time?
4. Security Testing: This is like checking if someone can easily steal your cake without you knowing! Is the program safe from hackers or people trying to break into it?

Here's how you typically go about testing and evaluating a computer program, like making sure your new game works perfectly:

1. Plan Your Tests: Before you even start, decide what parts of your game you need to check and how you'll check them. (e.g., "I'll test if the jump button works on all levels.")
2. Create Test Cases: Write down specific steps for each test. (e.g., "1. Press 'spacebar'. 2. Character should jump. 3. Character should land safely.")
3. Execute Tests: Run your game and follow each test case exactly. This is like playing your game specifically to find problems.
4. Record Evidence: Write down what happened for each test. Did the character jump? Did they land safely? Note any problems you find. This is your proof.
5. Identify Bugs: If something didn't work as expected, that's a bug (an error in the program). Mark it down clearly.
6. Evaluate Results: Look at all your evidence. How many bugs did you find? Are the important parts of the game working? Is it fun to play? This helps you decide if the game is ready or needs more work.

Even the best programmers make mistakes when testing. Here are some common ones:

• ❌ Only testing the 'happy path': This means only testing what happens when everything goes right (e.g., only testing 2 + 2 on your calculator). You assume users will always behave perfectly. ✅ How to avoid: Think like a mischievous user! Try to break your program. Test unusual inputs, wrong buttons, or things that shouldn't happen. What if someone types letters into a number field?
• ❌ Not recording evidence: Just saying "it works" without writing down how you know it works. This is like saying your cake is good without remembering if you actually tasted it. ✅ How to avoid: Always keep a test log (a document where you write down test steps, expected results, and actual results). Take screenshots or videos if something goes wrong. This evidence is crucial for fixing problems.
• ❌ Testing too late: Waiting until the very end to test your entire program. If you find a big problem, you might have to re-do a lot of work. ✅ How to avoid: Test often, test early! Test small pieces of your program as you build them. This is called incremental testing (testing in small steps) and helps catch problems before they become huge.
• ❌ Not considering the user: Building something you think is great, but not checking if actual users find it useful or easy to understand. ✅ How to avoid: Get real people to try your program! This is called user acceptance testing (UAT) and it's super important. Their feedback is gold, even if it means changing things.