Did you know that “the school website is broken” can be true but still too vague for anyone to fix? A student may be looking straight at a problem while a teacher, parent or school IT team sees the same page working normally. That does not necessarily mean the student imagined it. The two people may be using different devices, screen sizes or sequences of actions.
The most useful vocabulary is reproducible steps, expected result, actual result and environment. Reproducible steps describe a sequence another person can try; expected result states what should happen; actual result records what happened instead; and environment specifies relevant conditions such as application, device, browser version or accessibility setting. These terms turn a complaint into evidence that someone else can test—without asking a child to become a programmer.
A fictional classroom problem with one hidden clue
Imagine a Secondary 2 group using an invented class quiz website called Practice Garden. The quiz has ten Science questions. Farah enlarges browser text and page content to 200% because the original display is hard to read. She can answer the questions, but at the final screen the Submit button is no longer reachable in her window. Her friend’s laptop, at 100% zoom, shows the button clearly.
Farah tells the teacher, “The quiz is broken.” The teacher opens the page at ordinary zoom and sees the button. A good bug report changes the conversation: “On the practice quiz, with browser zoom at 200% and a narrow laptop window, the Submit button cannot be reached after question ten. I expected to see and activate Submit. I actually see the lower panel cut off, even after scrolling.” The example is entirely invented. It does not describe an actual eduKate or school platform.
The lesson is not that 200% zoom is wrong. Readability and accessibility are legitimate needs. The report should help the developer or support team test the page while respecting the student’s preferred reading conditions.
Five terms that make a report actionable
A bug is an unintended problem in a software system’s behaviour. A symptom is the observable effect; it may not identify the underlying cause. A workaround is a temporary way to complete a task without fixing the underlying problem. A fix is a change intended to address the underlying defect. A regression is a problem that appears after a change in software that previously behaved differently, if that earlier behaviour is verified.
Reproduce means make the same observable behaviour happen under stated conditions. Reproducible is the adjective: “The problem is reproducible when the page is enlarged.” Intermittent means the problem occurs sometimes but not every time. Do not write “reproducible” just because you personally saw a problem once; repeat the steps safely and record whether it happened again.
Useful collocations are reproduce an issue, observe a symptom, record actual behaviour, describe expected behaviour, provide an environment, test a workaround and verify a fix. Notice how these are verbs connected to evidence. They are better than calling someone else’s system “useless”, which neither narrows the problem nor makes the help request clearer.
Write a report that another person can actually follow
Here is Farah’s model report, with every name and system label invented for teaching. Title: “Submit button unreachable at 200% zoom in Practice Garden quiz”. Context: school-approved browser on a laptop, narrow window, page zoom 200%, demo practice account. Steps: open the practice quiz; set browser zoom to 200%; complete ten demo questions; go to the final review screen; try scrolling down to Submit. Expected: Submit stays reachable and operable. Actual: the bottom of the panel is clipped; the button cannot be selected. Frequency: observed on two attempts in this invented scenario. Impact: a learner cannot complete the submission at the chosen reading scale.
The report separates a task from a theory. The statement “the lower panel is clipped” is an observation. “The website uses bad CSS” is a possible diagnosis, not something the child has established. A useful reporter does not invent the cause to sound technically clever.
A teacher could try the same steps with a disposable demonstration account and note whether the issue persists at different window widths. If the quiz contains private student information, do not share a screenshot publicly. Crop or redact names, accounts and grades before sharing through an approved support route, and check whether filenames or embedded metadata could reveal details. Public issue trackers are not the place to paste passwords, access links, authentication tokens or children’s records.
Expected does not mean merely hoped for
A strong expected result follows the task’s purpose or published instructions. Suppose a website says, “Choose one answer, then select Next to proceed.” A reasonable expectation is that activating Next advances to the following item or gives a clear validation message. But if a student wants a feature that the platform never promised, that may be a feature request rather than a software defect. Vocabulary helps distinguish the two.
For example, “I expect a calculator to appear because that would be convenient” is a preference, not proof the current program is malfunctioning. “The instructions say the calculator icon opens a tool; selecting it produces no response” describes a mismatch between a stated function and observed behaviour. This distinction improves reading comprehension as well as software support.
Reproducible, intermittent and cannot reproduce
Consider three reports. Report A: the action fails on each of three safe demonstrations under the same conditions. The reporter can say the issue was reproducible in those attempts. Report B: the same action fails only once in five attempts. The reporter should call it intermittent or specify the observed frequency, not promise that it always happens. Report C: another tester follows the steps on a different browser and cannot reproduce the failure. That outcome does not automatically prove that the original experience was false; it suggests that one or more conditions may matter.
Ask the reporter to record differences that could change the outcome: screen or browser zoom, window size, network connectivity, device operating system, application version, sign-in state and the exact stage of the task. Avoid adding dozens of irrelevant details. Include only the smallest set that helps reproduce the observation while respecting privacy.
How this differs from debugging a program
A student studying Computing may already know syntax, runtime and logic errors. Those terms are useful for classifying how a program fails, but they are not prerequisites for writing a helpful report. A primary-school student can describe the exact action and screen. A Secondary G2 or G3 learner can add clear conditions and test a hypothesis. This article owns communication and reproducible reporting; eduKate’s separate guide to syntax, runtime and logic errors owns the deeper programming distinction.
The same way of thinking transfers to Mathematics. If a spreadsheet produces an unexpected total, describe the exact input cells, operation and output rather than simply saying “the spreadsheet is wrong”. It transfers to Science when reporting that a sensor stopped recording after a particular action. The key is to keep observed evidence distinct from a guessed explanation.
A seven-minute practice challenge for teachers
Provide three imaginary help requests on cards: “It crashed”; “Nothing works”; and “After I click Save on the sample form, I see a blank page rather than the stated confirmation”. Ask students to identify which has the most testable information. Then ask them to improve the first two cards by adding a safe, reproducible sequence and one expected-versus-actual pair. Younger learners can speak their steps aloud; older learners can write a concise report with headings.
For retrieval practice, hide the definitions and ask students to supply the terms: “It happens on some attempts but not others” (intermittent). “I can make the same failure occur by repeating these steps” (reproducible). “I used a different route that let me finish without fixing the bug” (workaround). “This is what I observed” (actual result). “This is what the instructions indicate should happen” (expected result). Review the cards a few days later using a new scenario.
Parents: help the child report, not just complain
When schoolwork fails, first confirm whether the deadline or task requires urgent teacher contact. Help the child capture the screen or error message safely if the school’s rules allow it. Ask, “What were you trying to do? What did the site say would happen? What happened? Can you show me safely, without sharing personal details?” A parent’s role is not to speculate about blame or demand that a child debug a school system. The role is to help produce a factual, polite report.
A useful respectful message is: “Hello, I could open the quiz but could not reach the final Submit button at 200% zoom. I have recorded the steps and the time. Could you advise on an accessible way to submit my work?” That wording requests support while preserving evidence. It does not claim that the school uses a particular system or promise that an IT team will fix it immediately.
Questions worth answering before sending
Do we know the exact screen and action, or only the feeling that something went wrong? Can an adult repeat the steps with a non-sensitive example? Did the expected result come from clear instructions or an assumption? Have we removed passwords, names and private records? Are we using the school’s approved help channel? These five questions catch most weak reports before they are sent.
Frequently asked questions
Must a bug always be reproducible? No. Intermittent failures and one-off incidents can still be worth reporting. Say precisely how often they occurred in your observations.
Is “cannot reproduce” an accusation? Not necessarily. It is a testing result under certain conditions. Compare environments, record new evidence and avoid treating either person as dishonest.
Is an unexpected result always a bug? No. It may reflect an incorrect expectation, a rule, a data-entry mistake or a real defect. Verify the intended behaviour before claiming a cause.
Does the screenshot replace the written report? No. A screenshot can show what was visible, but it may not tell the tester which steps produced that screen or what was supposed to happen.
The larger value of a precise vocabulary
A well-written bug report is a miniature scientific investigation. It names the conditions, the procedure, the observation and the uncertainty. This is why vocabulary matters to students, teachers, future developers, analysts and adults communicating about shared systems. Better words produce better questions, even before anybody writes a line of code.
For a concrete public example of the reporting structure, Microsoft’s open educational repository has a bug-report template with reproduction steps, expected behaviour and environment details. It is a model for learning the vocabulary, not an instruction to post school information to a public GitHub repository.