How to Write a Bug Report

Sorting the draft (step 1). It mixes three problems. First, the bill payment fails for some amounts: that is the main defect and gets its own report. Second, the pay button label is cut off in the Arabic UI at a narrow width: a separate defect with its own cause, fix and lifecycle, so it gets its own report too. Third, "the error message is useless": a generic message is reasonable behaviour for an unexpected server error, BILL-3 says nothing about error wording, and once the 500 is fixed these payments no longer show it. It is not a defect; if you think the wording should change, raise it with the product owner as a separate improvement suggestion. The copied request and the 500 response are not problems of their own: once cleaned (step 5), they go inside the main report as evidence. The rest goes into no report: "totally broken", "URGENT" and "ASAP" are opinion, and "error every time" is an unmeasured claim that runs 1 and 6 disprove.

Isolating the trigger (step 2). Runs 1 and 2 differ only in the amount: 250.00 succeeds and 250.75 fails, and run 3 repeats run 2 with the same result, so it is not a one-off. Changing the browser (run 4) changes nothing. Run 5 changes the account, the biller and the amount at once and still fails, so the failure needs none of those particular values. Run 6 (1000.00) succeeds like run 1. The trigger is therefore an amount with a non-zero decimal part. Run 7 succeeds on 7.2.4, which points to a regression introduced in 7.3.0; but UAT differs from staging in more than the build, so report it as a strong hint, not as a proven fact. The log line tells the developer where to look (AmountMapper.java:58), but the tester gives it as evidence, not as a diagnosis in the title.

Model report for the main defect. Title: Pay a bill returns 500 and creates no payment when the amount has a non-zero decimal part, e.g. 250.75. Environment: web banking 7.3.0 on staging, English UI; Chrome 129 / Windows 11, also reproduced on Firefox 131 / Windows 11; retail customer role, test accounts test-cust-07 and test-cust-12. Severity: Critical. Priority: High. Frequency: Always — all 4 attempts with such an amount failed (runs 2 to 5), and both whole amounts succeeded.

Preconditions: logged in as a retail customer (for example test-cust-07) with a saved biller (Electricity, BLR-ELEC-01) and an account (ACC-TEST-0007) whose balance covers the amount. Steps to reproduce: 1. Open Payments > Pay a bill. 2. Choose the biller Electricity and the account ACC-TEST-0007. 3. Enter 250.75 in Amount. 4. Click "Pay bill".

Expected result: the payment is created, the confirmation page shows a reference number, the payment appears in the account history with the same number, and the balance drops by 250.75 (BILL-3: any amount from 1.00 to 10,000.00 SAR with up to two decimal places). Actual result: a red banner shows "Something went wrong. Please try again later."; POST /api/v2/bill-payments returns 500 with the body {"error":{"code":"INTERNAL","message":"Unexpected error","requestId":"b7e2-41c9"}}; no payment appears in the history and the balance is unchanged.

Evidence: a screenshot of the banner; the response above; the server log line for request id b7e2-41c9, java.lang.NumberFormatException: For input string: "250.75" at bank.payments.AmountMapper.toMinorUnits(AmountMapper.java:58); and the request as a cleaned cURL command: curl 'https://staging.bank.example/api/v2/bill-payments' -H 'accept: application/json' -H 'authorization: Bearer [REDACTED]' -H 'content-type: application/json' --data-raw '{"billerId":"BLR-ELEC-01","fromAccount":"ACC-TEST-0007","amount":"250.75"}'. The bearer token is replaced with [REDACTED] because anyone who can read the tracker could use it while it is valid; the developer puts a token for their own test account in its place. The whole -b option goes too: it carries the session cookie, which is just as usable, and the _ga analytics cookie. In a copied command, cookies can sit in -b rather than in a header, so check both places when you redact. The accept-language, sec-ch-ua-platform and user-agent headers go because the browser adds them on its own and run 4 shows the browser makes no difference. The accept and content-type headers stay because they describe what the request sends and what it expects back; without content-type, curl would label the --data-raw body application/x-www-form-urlencoded. In real work, run the cleaned command once with a fresh token of your own before attaching it: if it still returns the 500, nothing you removed was needed.

Notes: whole amounts succeed (250.00, 1000.00); the failure does not depend on the browser, the account or the biller (runs 4 and 5). The same payment of 250.75 succeeds on UAT, which runs 7.2.4, so 7.3.0 probably introduced it; UAT differs from staging in more than the build, so this is a strong hint rather than proof. No open defect was found for bill-payments or NumberFormatException.

Why Critical: go down the guide’s severity scale from the top. Blocker does not fit, because bill payment still works for whole amounts. Critical does: this is a failed payment, and a customer cannot pay the exact amount of any bill that has a decimal part. Some teams would argue for Blocker because many real bills have a decimal part; with that reasoning either level is defensible, but Major or lower is not, because payments fail. Why High: production still runs 7.2.4, the build on which the same payment succeeds in UAT, so releasing 7.3.0 with this defect would make every bill payment with a non-zero decimal part fail for customers — it must be fixed before release. Had 7.3.0 already been live, the priority would be Highest. As the tester you propose the priority; the triage meeting or the product owner decides it.

Second report. Title: Pay bill button label is cut off in the Arabic UI at 360 px viewport width. Environment: web banking 7.3.0 on staging, Chrome device toolbar at 360 px; the label fits at 412 px, and the English label fits at 360 px. Severity: Minor — cosmetic, the button still works. Priority: Medium, proposed (next sprint), because it is the main action on the page for Arabic users on narrow phones; the product owner may raise it to High before release. Attach screenshots at 360 px and at 412 px and, if you can, confirm on a real phone of that width and name it: device emulation is not the device.

After the fix: confirmation testing repeats the exact steps with 250.75 and 99.50. Add regression checks around the change: whole amounts, the boundaries of BILL-3 (1.00 and 10,000.00 accepted, 0.99 and 10,000.01 rejected), an amount with one decimal place such as 250.5 (accepted) and one with three such as 250.755 (rejected, because BILL-3 allows at most two).

Check your own work. Your report is complete if a developer who never saw the draft could reproduce the failure from your steps alone; the title names the symptom, the place and the condition with no opinion; the steps use one exact amount and leave the other runs to the notes; the expected result cites BILL-3; the actual result quotes the banner, the status code and the request id exactly; the token is redacted and the cookies are gone; severity and priority are set separately, each with a reason; and neither the button defect nor the complaint about the error message’s wording is in this report. In ISTQB terms you observed a failure — the 500 and the missing payment; the report gives the developer what they need to find the defect behind it, and the log line is evidence, not your diagnosis.