A good bug report: a defect that gets fixed on the first try

Half of a developer's time on a defect goes not into fixing but into understanding: what exactly broke, how to repeat it and how urgent it is. A bug report exists to close these three questions before they are asked.

Mandatory fields

• Title: where and what — "Cart: promo code not applied on second entry on iOS". The title should tell whether to drop everything.
• Steps to reproduce: a numbered list of actions with concrete data — which account, which product, which promo code. No "tried different ways".
• Expected result: what should have happened by the requirements or common sense.
• Actual result: what happened — error text, screen state, what remained in the data.
• Environment: build or version, device, OS, browser, interface language, test or production stand.
• Attachments: a screenshot with highlighting, a screen recording for multi-step flows, logs or the server response if available.
• Severity and priority — two different fields, see below.
• Frequency: reproduces always, sometimes, once — this affects the approach to fixing.

Severity and priority are not the same

Severity answers "how serious is this for the product", priority answers "how urgently should it be fixed". A typo in the home page headline before an ad campaign launch has low severity and high priority. A crash in a rare export one client uses once a quarter has high severity and low priority. The tester sets severity on a scale, the product owner sets priority, and a dispute between them is normal.

1. Blocker — the flow cannot continue: does not open, does not pay, loses data.
2. Critical — a core function works incorrectly: wrong amount, wrong terms, an error in a notification.
3. Major — the function works with significant inconvenience or via a workaround.
4. Minor — cosmetics and small inaccuracies that do not affect the result.

What a bug report must not contain

• Judgements and emotions: "terrible", "again", "as usual".
• Several defects in one: each is a separate ticket, otherwise half of it closes as "partially".
• Guesses about the cause instead of facts: "probably the cache" — only with evidence.
• Steps without data: "enter a promo code" instead of "enter promo code SPRING25 for account test_user_4".
• A screenshot without context: a cropped address bar, no time, no highlight of the problem spot.

Example

Title: "Payment: on gateway timeout the order is created twice (Android, build 2.8.0)". Steps: sign in as test_user_4; add an item above the minimum amount; choose card payment; wait on the gateway screen until the timeout expires; return to the app. Expected: one order in "awaiting payment". Actual: two orders with identical contents, both "awaiting payment", the creation push arrived twice. Environment: pre-production, Android, budget model, Russian interface. Reproduces always. Severity: critical. Attachments: screen recording, gateway response from logs.