Foundation · 45 MINUTES · VERSION 1
Explain a bug and fix in simple English
Write reproducible steps, expected/actual results, a focused correction and honest verification limits.
Reviewed 23 Oct 2026Your setup may differ. Windows, Ubuntu, and optional tool bundles →
What you will learn
- Write a short bug report with reproducible evidence.
- Separate an observed result from a guess about the cause.
- Explain a fix and its verification in simple English.
Theory: make another person's next step clear
A useful report tells a teammate what to do and what to check. Use short sentences. Name the affected feature. Describe the expected result before the actual result. Add exact steps, dummy input, environment/version and impact. “It does not work” is hard to act on.
Observation is what you measured. A hypothesis is an explanation to test. “Maya shows one task” is an observation; “COUNT(*) counts the unmatched join row” is a hypothesis until you check the query and fixture. A fix summary should state what changed and why it matches the requirement. Do not claim more testing than you performed.
Worked example: report a counting bug
Use the original people/tasks fixture from the SQL lesson, on your own isolated practice database. Maya has no tasks. Run the all-task LEFT JOIN count with COUNT(*) instead of COUNT(t.id). The trusted SQL lab verifies this faulty result is 1 for Maya and the corrected result is 0. Do not change the learning application's data.
Title: Task report counts one task for a person with no tasks
Environment: MySQL 8.4; original three-person practice fixture
Steps:
1. Load the original practice fixture.
2. Run the LEFT JOIN all-task report with COUNT(*).
3. Read Maya's task_count.
Expected: Maya has 0 tasks.
Actual: Maya has 1 task.
Impact: The report overstates work for people without tasks.
Cause checked: COUNT(*) counts the unmatched result row.
Fix: Count the non-null task ID with COUNT(t.id).
Verified: Asha 2, Robin 1, Maya 0 on the original fixture.
Not checked: Production data and browser display.
The title identifies behavior rather than blaming a person. The expected counts make the requirement testable. The final limitation prevents a teammate from reading a local SQL check as a production release claim. Real customer names, tokens, database credentials and screenshots containing private data do not belong in a public report.
Guided practice
- Read the report aloud. Pause after each sentence.
- Run the faulty query and record the actual value before reading the fix.
- Apply only the count-expression correction; compare all three people.
- Rewrite the fix in two sentences: “I changed __ because __. I tested __.”
- Add a regression case for a new person with no tasks. State your changed fixture honestly.
Keep the useful technical words in English: query, LEFT JOIN, COUNT, fixture, expected, actual, regression. You do not need difficult vocabulary to explain precise evidence.
Independent exercise
Write a report for the Laravel preview receiving an array title instead of text. Include the JSON-expecting request, expected 422/title error, actual result from your own run, and the relevant feature test. If your run already behaves correctly, call it a verification report, not a new bug. Explain what would fail if the string rule were removed. Do not invent a production incident or test result.
Common mistakes
- Mixing several unrelated bugs into one report.
- Stating an untested guess as the root cause.
- Omitting input/version or changing the fixture without saying so.
- Writing “all tests passed” after running only one check.
- Copying secrets or customer records into evidence.
Self-check — not graded
- Which comes from measurement: actual result or hypothesis?
- Why include a person with no tasks in verification?
- What should you write if production was not tested?
Interview practice
“Tell me about a bug you fixed.” Use four parts: problem, evidence, change, verification. Explain one limitation or tradeoff. Use your real project experience when applying for a job; this practice fixture is a learning exercise, not employment history.
English practice and glossary
- Expected: what the requirement says should happen.
- Actual: what you observed.
- Impact: who or what the issue affects.
- Hypothesis: an explanation that needs checking.
- Regression test: a check that protects corrected behavior.
Practise: “I can reproduce it with __.” “The result should be __, but it is __.” “I checked __; I have not checked __.” Record a 60-second explanation locally if useful. This site does not automatically assess your pronunciation.
Recap and next step
Clear evidence matters more than complex English. Give reproducible steps, honest results and a focused fix. Next, combine these skills in the task-report project. The writing reference below was checked on 2026-10-22.
Reveal exercise hints and self-check answers
- The actual result is measured; the hypothesis is an explanation to investigate.
- It checks the missing-child edge case that exposed the counting bug.
- Say explicitly that production was not tested.
Self-review rubric: give yourself one point each for a clear title, reproducible dummy input/steps, expected/actual result, measured verification, and an honest limitation. This is self-assessment, not a server-graded writing score. Rewrite a weak section and read it aloud again.