English:Debugging and Testing
Debugging and Testing
Introduction
Software rarely works perfectly the first time. A character may move in the wrong direction, a score may be calculated incorrectly, a button may do nothing, or a program may stop with an error. Finding out why something went wrong is called debugging. Checking whether software behaves as expected is called testing.
In this aiMOOC, you will learn a practical way to find bugs, design useful test cases, compare expected and actual results, and report problems clearly. The course is written for Grades 7–8, but the same habits are used in professional software development.
The famous 1947 logbook from the Harvard Mark II computer contains a moth that was found in a relay. The operators described it as the first actual case of a bug being found. The word bug had already been used for technical faults before this event, so the moth did not invent the word. It became a memorable symbol of debugging.
The video above introduces a useful idea: test a small part of your program at a time. Small tests make it easier to locate the part that causes a problem.
Learning Goals
By the end of this aiMOOC, you should be able to explain the difference between a bug, debugging, and testing; recognize common bug types; create test cases with expected results; use normal, edge, and invalid inputs; follow a systematic debugging cycle; explain basic unit, integration, and end-to-end tests; describe regression testing; and write a clear bug report.
Bugs, Debugging, and Testing
A bug is a defect or problem in software that can make the program produce an incorrect result, behave unexpectedly, or fail to complete a task.
Debugging is the process of locating, understanding, and fixing the cause of a bug. Debugging usually begins after you notice evidence that something is wrong.
Testing is the planned process of checking software by giving it inputs or actions and comparing what actually happens with what should happen. A good test has a clear expectation.
Testing and debugging support each other, but they are not the same activity. A test can reveal that a problem exists. Debugging investigates the cause and changes the program. After the change, the test is run again to check the fix.
| Idea | Main question | Simple example |
|---|---|---|
| Bug | What is wrong? | A quiz gives 8 points when the correct score is 10. |
| Testing | Does the program behave as expected? | Try three quiz answers and compare the displayed score with the expected score. |
| Debugging | Why is the result wrong, and how can it be fixed? | Inspect the score calculation, find the faulty rule, correct it, and test again. |
Common Types of Bugs
You do not need to memorize every possible programming error. It is more useful to recognize a few common patterns.
| Bug type | What it means | Example | Useful first step |
|---|---|---|---|
| Syntax error | The code breaks a rule of the programming language. | A closing quotation mark is missing. | Read the error message and inspect the reported line and nearby lines. |
| Runtime error | The program starts, but an error occurs while it is running. | The program tries to divide a number by zero. | Reproduce the problem and note the input that caused it. |
| Logic error | The program runs, but its result is wrong. | A game adds points when it should subtract them. | Compare intermediate values with what you expected. |
| Input error | The program does not handle a certain input correctly. | A name field accepts an empty value when a name is required. | Try normal, edge, and invalid inputs. |
| Integration error | Two parts work separately but fail when they work together. | A game saves a score correctly, but the scoreboard reads it incorrectly. | Test the connection between the two parts. |
A single problem may fit more than one category. The purpose of categories is to guide your investigation, not to attach a perfect label to every bug.
A Systematic Debugging Cycle
Randomly changing code can make debugging slower because you may not know which change helped. A better method is to collect evidence and change one thing at a time.
| Stage | What you do | Question to ask |
|---|---|---|
| Reproduce | Make the problem happen again using known steps or input. | Can I make the same problem happen twice? |
| Observe | Record error messages, wrong outputs, variable values, or unusual behavior. | What exactly happened? |
| Isolate | Reduce the problem to the smallest part that still fails. | Which line, block, function, input, or connection is involved? |
| Explain | Form a possible reason for the failure. | What evidence supports my idea? |
| Change | Make one focused correction. | What is the smallest safe change I can try? |
| Retest | Run the failing test again. | Does the original problem now pass? |
| Check nearby behavior | Run other important tests to look for side effects. | Did the fix break something that used to work? |
A good debugger is a detective. Instead of guessing, you use clues. Error messages, printed values, logs, screenshots, test results, and small experiments can all be evidence.
Useful Debugging Techniques
Read the message carefully. Error messages often tell you the type of problem and where the computer noticed it. The reported line is a starting point, not always the exact cause.
Trace values. Check important variables at several points. If a score should change from 20 to 25 but becomes 15, inspect the calculation just before the value changes.
Use a smaller example. A program that fails with a list of 100 items may be easier to understand with a list of 3 items.
Compare working and failing cases. Ask what is different. If every positive number works but zero fails, zero is an important clue.
Change one thing at a time. If you edit five different lines before testing again, you may not know which change fixed the problem or created a new one.
Ask another person to reproduce it. A classmate may notice a missing step or a different interpretation of the instructions.
Testing with Clear Expectations
A test case is a planned check of a particular behavior. A simple test case states what you do, what input you use, and what result you expect.
Suppose a program has a function called double that should return twice a number.
FUNCTION double(number)
RETURN number + number
END FUNCTION
A basic test table could look like this:
| Input | Expected result | Actual result | Outcome |
|---|---|---|---|
| 3 | 6 | 6 | Pass |
| 0 | 0 | 0 | Pass |
| -4 | -8 | -8 | Pass |
The expected result should be decided before you judge the actual result. Otherwise, you may accidentally accept a wrong result just because it looks reasonable.
Normal, Edge, and Invalid Tests
Using only one easy input is rarely enough. Strong testing includes different kinds of cases.
| Test kind | Meaning | Example for an age field that accepts ages from 10 through 14 |
|---|---|---|
| Normal | A typical valid value. | 12 |
| Edge | A value at or very near a boundary. | 10 or 14 |
| Invalid | A value that should be rejected or handled safely. | 9, 15, or an empty entry |
An edge case matters because many bugs appear at boundaries. A programmer may accidentally write a rule that accepts values greater than 10 when the real rule should accept values greater than or equal to 10.
Worked Example: Finding a Logic Bug
Imagine this pseudocode is meant to report whether a number is even:
FUNCTION isEven(number)
RETURN number MOD 2 = 1
END FUNCTION
Before changing the code, design tests.
| Input | Expected result | Actual result from the faulty code | What the test tells you |
|---|---|---|---|
| 2 | true | false | The rule is reversed for an even number. |
| 5 | false | true | The rule is reversed for an odd number. |
| 0 | true | false | Zero reveals the same logic problem. |
The tests give a strong clue: the program is checking for a remainder of 1, which describes odd whole numbers. A focused correction is:
RETURN number MOD 2 = 0
Now run the same tests again. If they all pass, keep them for later. They can help detect a regression if a future change accidentally reintroduces the problem.
Black-Box and White-Box Thinking
In black-box testing, you focus on inputs and visible outputs without using the internal code to design the test. For example, you may test a calculator by pressing buttons and checking the answer.
In white-box testing, you use knowledge of the program's internal structure. For example, you may choose inputs because you know there is an if-statement with two branches and you want both branches to run.
At Grades 7–8, you can use both ideas even without advanced tools. Testing a classmate's project without reading the code is black-box thinking. Reading your own code and choosing tests for each branch is white-box thinking.
Levels of Software Testing
Different tests can focus on different sizes of a system.
| Level | What it checks | School-project example |
|---|---|---|
| Unit test | One small part, such as a function or calculation. | Does the function that adds two scores return the correct total? |
| Integration test | Whether two or more parts work together correctly. | Does the quiz send the final score correctly to the scoreboard? |
| End-to-end test | A complete user path through the system. | Can a learner start the quiz, answer questions, submit, and see the final result? |
The testing pyramid is a model that encourages many small, fast tests and fewer large, slower tests. It is a guide rather than a law. The right mix depends on the project.
A unit test checks a small part of a program in isolation. Unit tests are especially useful when a function has clear inputs and expected outputs.
Regression Testing and Automated Tests
A regression is a problem that appears when a new change breaks behavior that previously worked. Regression testing means rerunning important tests after a change to check that old features still work.
Some tests are manual: a person follows steps and observes the result. Other tests are automated: code or a testing tool runs checks and reports whether the expected conditions were met.
Automation is useful for tests that must be repeated often, but an automated test is only as useful as the behavior it checks. A program can pass all existing tests and still contain an untested bug. Testing increases confidence; it does not prove that software is perfect.
Test-Driven Development as a Stretch Idea
Test-driven development is a method in which a programmer writes a small automated test before writing the code that should satisfy it. A common cycle is called red, green, refactor: first create a test that fails, then write enough code to make it pass, and finally improve the code while keeping the tests passing.
You do not need to use test-driven development for every school project. The useful lesson is that expected behavior can be written down before implementation, and tests can guide the programmer toward clear goals.
Writing a Helpful Bug Report
A bug report should help another person reproduce and understand a problem. Avoid vague reports such as "It does not work." Give enough evidence for someone else to repeat the same issue.
| Part of a bug report | Example |
|---|---|
| Short title | Score becomes negative after using a hint |
| Starting situation | Quiz is open on Question 5 with a score of 2 |
| Steps to reproduce | Select Hint, then choose the correct answer |
| Expected result | Score should stay at 2 because the hint already removed one point |
| Actual result | Score becomes -1 |
| Evidence | Screenshot and the exact question number |
| Environment | Browser or device where the problem appeared |
A respectful bug report describes the software behavior, not the person who wrote the code. The goal is to make the problem understandable and fixable.
Team Testing Challenge
In pairs, choose a small program, Scratch project, website prototype, spreadsheet formula, or classroom app that you are allowed to test. One learner acts as the tester and creates a short test table. The other acts as the developer and tries to reproduce any failure. Then switch roles.
Use this cycle: agree on the expected behavior, try normal and edge cases, record actual results, isolate one failure, make one focused correction if you control the project, and rerun the original test plus nearby tests.
If your project uses Scratch, the following beginner-friendly example shows how to identify and fix common bugs step by step.
Interactive Tasks
Quiz: Test Your Knowledge
What is the main purpose of debugging? (To find, understand, and fix the cause of a software problem) (!To make every program longer) (!To remove all test cases) (!To choose a new programming language)
What does a test case compare? (An expected result with an actual result) (!A computer brand with a keyboard brand) (!A file name with a folder color) (!A programmer with a user)
Which example is a logic error? (A program runs but calculates the score incorrectly) (!A missing quotation mark stops the code from being parsed) (!A computer has no electrical power) (!A user forgets the website address)
Why are edge cases useful? (They can reveal problems at boundaries or unusual limits) (!They guarantee that no bugs exist) (!They replace all normal test cases) (!They make error messages disappear)
What should you do first when trying to debug a reported problem? (Try to reproduce the problem) (!Rewrite the entire program) (!Delete the test that failed) (!Change many lines at once)
What is a regression? (A change causes behavior that used to work to fail) (!A program is translated into another language) (!A tester creates a new password) (!A file is moved into a folder)
What does a unit test usually check? (One small part of a program) (!Every computer on the internet) (!Only the visual design of a whole website) (!The age of the programmer)
What does black-box testing focus on? (Inputs and visible outputs) (!The color of the source code) (!Only comments inside the program) (!The programmer's typing speed)
What is the best debugging habit when trying a possible fix? (Change one focused thing and test again) (!Change many unrelated things before testing) (!Ignore the original failing input) (!Remove all error messages)
What makes a bug report especially useful? (Clear steps, expected behavior, actual behavior, and evidence) (!A message that only says it is broken) (!A guess about who caused the problem) (!A list of unrelated software names)
Memory Game
| Debugging | Finding, understanding, and fixing the cause of a software problem |
| Test case | A planned check with an input or action and an expected result |
| Regression | A new change breaks behavior that worked before |
| Boundary | A limit where edge cases are especially useful |
| Reproduce | Make the same problem happen again using known steps |
| Unit | A small part of a program tested on its own |
| Assertion | A check that compares actual behavior with an expected condition |
Drag and Drop
| Match the correct terms. | Topic |
|---|---|
| Syntax error | Code breaks a rule of the programming language |
| Logic error | Program runs but gives the wrong result |
| Edge case | Input lies at or near an important boundary |
| Regression test | Check that earlier working behavior still works after a change |
| Bug report | Clear record of steps, expected behavior, and actual behavior |
...
Crossword Puzzle
| Debugging | What process finds, understands, and fixes the cause of a software problem? |
| Syntax | What kind of language rule can be broken by a missing quotation mark? |
| Boundary | What limit is especially important when choosing edge cases? |
| Regression | What problem appears when a change breaks behavior that worked before? |
| Reproduce | What verb means to make the same problem happen again? |
| Assertion | What word names a check that expected and actual conditions agree? |
LearningApps
Cloze Text
Open-Ended Tasks
Easy
- Bug Hunt: Find a small bug in a Scratch project, simple program, spreadsheet formula, or teacher-provided example. Describe what you expected, what actually happened, and how you reproduced it.
- Test Table: Create a table with at least six test cases for a simple calculator or quiz function. Include normal, edge, and invalid inputs and predict the expected result before testing.
- Error Message Translator: Collect three safe classroom error messages from a coding activity and rewrite each message in plain English for a beginner.
- Bug Report Poster: Design a one-page poster that teaches classmates how to write a useful bug report with steps, expected behavior, actual behavior, and evidence.
Standard
- Pair Debugging Interview: Interview a classmate about a bug they solved. Record the clues they used, the wrong ideas they rejected, the fix they tried, and how they checked the result.
- Boundary Test Lab: Choose a program with a numeric limit, such as age, lives, score, or password length. Design and run tests just below, at, and just above the boundary, then explain what you learned.
- Black Box Challenge: Test a classmate's small program without reading its code. Infer one possible rule from the inputs and outputs, then compare your idea with the real code afterward.
- Regression Mini Project: Start with a working small project, make one planned feature change, and rerun a saved test set. Document whether any earlier behavior stopped working.
Advanced
- Automated Test Prototype: Write or adapt a small program with at least three automated checks for a function. Make one check fail on purpose, diagnose the cause, fix it, and show the passing result.
- Integration Investigation: Build or examine a project with two connected parts, such as a quiz and scoreboard. Create tests for each part alone and for the connection, then explain which test finds which kind of problem.
- Debugging Screencast: Produce a short narrated video that shows a real or teacher-provided bug from reproduction through evidence, focused fix, and regression test. Keep personal information out of the recording.
- Testing Strategy Review: Compare two small projects and design a testing strategy for each using unit, integration, and end-to-end thinking. Justify why the mix of tests should differ between the projects.
Learning Assessment
- Evidence-Based Debugging: Given a faulty program and three test results, identify the most likely location of the problem, explain the evidence, propose one focused change, and state which tests you would rerun.
- Test Design Assessment: Design a balanced set of tests for a rule with clear boundaries. Explain why each test is normal, edge, or invalid and what failure it could reveal.
- Bug Report Quality: Compare two bug reports about the same problem, decide which one would help a developer more, and rewrite the weaker report so that another learner can reproduce the issue.
- Testing Levels Transfer: For a school app with login, quiz, and score display, propose one unit test, one integration test, and one end-to-end test, then explain what each test can and cannot show.
- Regression Reasoning: A new feature works, but an older feature fails afterward. Explain why this is a regression, design a small regression test set, and justify which tests should be run after the fix.
- Debugging Reflection: Analyze a debugging session of your own. Distinguish observation from assumption, identify the most useful clue, and explain how you would improve your process next time.
Evidence of Learning
| Area | Evidence you can show |
|---|---|
| Knowledge | You can explain bugs, debugging, testing, expected results, edge cases, unit tests, integration tests, end-to-end tests, and regression testing in your own words. |
| Skills | You can reproduce a failure, collect evidence, isolate a likely cause, make one focused change, and retest. |
| Test design | You can create normal, edge, and invalid cases and state the expected outcome before running them. |
| Communication | You can write a bug report that another learner can follow without guessing. |
| Products | You can produce a test table, debugging record, bug report, screencast, or automated test prototype. |
| Transfer | You can apply the same testing habits to a new program, Scratch project, website prototype, spreadsheet, or digital tool. |
OERs on the Topic
The following English Wikipedia pages provide background reading on two central parts of this topic.
Linked Learning Areas
Debugging and testing connect programming with logical reasoning, communication, mathematics, digital literacy, and teamwork. You use logic to form explanations, mathematics to choose meaningful inputs, language skills to report problems clearly, and collaboration to reproduce and fix issues responsibly.