Bug Fixing

Salary

This task pays a fixed salary of 18 MVP points, plus up to 36 quality points for exceeding the minimum requirements — for a total of 54 points, with a maximum of 9 points per person.

Minimum Viable Product (MVP)

During development your team must report one reproducible bug and later fix it, proving that the same steps no longer reproduce the problem. Resist the urge to “quick-fix while coding”; first capture the bug clearly, then schedule the fix. The bug report should state what you did, what you expected, and what actually happened, so any teammate (or tutor) can follow it.

To complete MVP, create one GitLab issue labeled bug that includes: a short title, Steps to Reproduce (numbered), Expected vs Actual result, and any evidence (error text/screenshot, sample input). After fixing, comment on the same issue with a short proof (e.g., terminal snippet or screenshot) that the steps no longer fail, then close the issue. The point is not deep testing—just clean, repeatable attempts and correct documentation.

Example: Team 'ByteBusters' log before they fix

They discover: searching with an empty keyword crashes. They open Bug #12 with steps (start app → choose Search → press Enter), expected (“show ‘Please type a keyword’”), actual (traceback). They attach the exact input. They do not fix immediately; they plan it for the next session and move on.

Technical Details

Use (or paste) a tiny bug template in the issue: - Title: “Crash on empty search” - Environment: OS, Python/Java version, commit hash - Preconditions: sample data file if needed (attach) - Steps to Reproduce: 1…N (keep them minimal) - Expected / Actual: one–two lines each - Evidence: error text/screenshot

Assign an owner, add labels bug. When fixing: create a branch (e.g., fix/empty-search), optionally add a small regression check (pytest/JUnit or a tiny script that runs the scenario), implement the fix, and reference the issue in your commit/MR (Closes #12). Re-run the exact steps and post a short “cannot reproduce anymore” comment with output, then close.

Quality

Quality means your bug work is clear, verified, and teachable. Show at least two reproducible tries before the fix (e.g., with a different input or file) and a simple root-cause note (“empty string was not handled”). If possible, include a tiny regression test so the bug doesn’t come back; if not, provide a one-command script that demonstrates the fixed behavior. Keep the report readable for an end user: focus on what they see, not a code tour.

Also demonstrate basic discipline: you separate reporting from fixing (no multitasking), you explain why the fix works in one sentence, and you link any related feature issue. The result is a small, professional bug lifecycle: report → triage → fix → verify → close, “it works” level.

Example: Team 'NullPointers' close the loop

Bug #7: “Load CSV shows wrong count.” They document two runs (small and medium file), expected vs actual, and attach the CSV. Root cause: off-by-one when skipping header. They add a tiny pytest checking the count, fix the loop, post the passing output, and close the issue.

Example: Team 'PixelPenguins' make it reproducible

Their automaton misbehaves on a 3×3 grid corner. Bug #4 includes a mini grid in the issue and exact toggle steps. After fixing a boundary check, they attach a screenshot of the corrected generation and a short script that reproduces the scenario successfully.