Defect Management

Severity: Low. It is a cosmetic typo — nothing is broken, no data is lost, payment still works.
Priority: P1 (Urgent). A board press demo tomorrow makes a visible typo on the checkout page embarrassing and time-critical, so it must be fixed today.

Why they differ: severity measures technical impact (how badly is the system broken?), priority measures business urgency (how soon must we fix it relative to everything else?). They are independent dimensions. This is the textbook low-severity / high-priority case: trivial bug, but a business deadline drives the urgency. Testers own severity; product/business owns priority.

A complete report (specifics invented but plausible):

Title: Login fails with HTTP 500 when the password contains an ampersand (&) on the customer portal.

Steps to reproduce:
1. Go to https://portal.example.co.nz/login on Chrome.
2. Enter a valid registered email (e.g. test.user@example.co.nz).
3. Enter a password containing an ampersand, e.g. "Pass&word1".
4. Click "Log in".

Expected result: User is authenticated and lands on the account dashboard.
Actual result: Page returns an HTTP 500 error and a generic "Something went wrong" message. The user is not logged in. Reproduces every time with an ampersand in the password; logins without special characters succeed.
Environment: Chrome 124 on Windows 11; UAT environment, build 2.14.0.
Evidence to attach: screenshot of the 500 page, the server log snippet showing the unescaped-character exception, and a screen recording of the reproduction.

Why this is better than the original: the original had no steps, no environment, no expected vs actual, and no evidence, so the developer would have to chase the tester for everything. A good report lets the developer reproduce the bug without asking a single question.

Lifecycle walkthrough:
- New — Tester: logs the defect with steps, expected vs actual, severity High, evidence (a worked example of an under-paid employee).
- Assigned — Lead/Manager: triages, confirms severity and priority (compliance + staff under-payment makes it P1), assigns to a developer.
- Open / In Progress — Developer: investigates and fixes the mid-year hours-change calculation.
- Fixed — Developer: code change made, ready for retest; notes which build contains the fix.
- Retest — Tester: confirms the original case now pays correctly, and runs a regression on the surrounding payroll logic.
- Closed — Tester: verified fixed in all affected environments; defect closed with a note linking the fix.

5 Whys (example chain):
1. Why was holiday pay wrong? Because the calculation used the latest hours, not the average across the period.
2. Why did it use the latest hours? Because the requirement for mid-year hours changes was never specified.
3. Why was it never specified? Because the Holidays Act averaging rule was not captured in the acceptance criteria.
4. Why was it not captured? Because no one with payroll-compliance knowledge reviewed the story.
5. Why was there no compliance review? Because the team has no checklist step for legislative requirements.

Root cause: a missing compliance-review step in the requirements process, not a coding slip.
Process improvement: add a mandatory legislative/compliance review (and a Holidays Act test checklist) to the definition of done for any payroll-calculation story, and add boundary test cases for mid-year changes to the regression suite. The point of RCA is to prevent the class of bug, not just patch the one instance.