Bugs

reports, severity, life cycle

What should a good bug report contain?

Title: what, where, under what condition. Not "transfer doesn't work" but "Transfer fails with 500 if the amount has 3 decimal places".
Environment: build, browser, OS, device, user.
Preconditions and steps to reproduce, minimal.
Actual and expected result.
Evidence: a screenshot, video, log, the request and response from DevTools.
Severity, priority, reproduction rate.

Title:        [Payments] Transfer returns 500 if the amount has 3 decimal places
Environment:  staging, build 2.14.3, Chrome 129, Windows 11
Preconditions: user qa_user_03, balance 5,000.00 UAH
Steps:
  1. Open "Transfer to card"
  2. Enter the amount 100.555
  3. Click "Continue"
Actual:       the error "Something went wrong"; POST /api/transfers → 500
Expected:     field validation "No more than 2 decimal places", the request is not sent
Reproducible: 5/5
Attachments:  video.mp4, HAR file, request/response

In an interview: A good report has a title that makes clear what is broken and under what condition, the environment, minimal steps, the actual and expected result and evidence: a screenshot, video, the request and response from DevTools. The goal is for the developer to reproduce the bug without a single question to me.

How does severity differ from priority?

Severity is how strongly a defect affects the system. Determined by QA.

Priority is how urgently it must be fixed. Determined by the business or the PM.

	High priority	Low priority
High severity	Payments don't go through	A report used once a year crashes
Low severity	A mistake in the bank's name on the home page	A pixel shifted in the footer

In an interview: Severity is the technical impact of a defect on the system, and QA determines it. Priority is how urgently to fix it, and that is the business's decision. They don't always coincide: a typo in the bank's name on the home page is low severity, but high priority, because it hits the reputation.

What is the life cycle of a bug?

Typically: New → Assigned → In Progress → Fixed → Ready for QA → Verified → Closed.

Branches: Reopened (the retest failed), Rejected / Not a bug, Duplicate, Cannot reproduce, Deferred / Won't fix. The specific statuses depend on the Jira workflow on the project.

In an interview: A bug is created, assigned to a developer, fixed, returned to QA, I do a retest and close it. If the retest failed, I reopen it. There are also statuses like duplicate, cannot reproduce, not a bug or deferred. The exact workflow depends on the Jira settings on the project.

What do you do if a bug doesn't reproduce?

Repeat under exactly the same conditions: environment, build, user, data, browser.
Collect more data: logs, console, network, the time of the incident, the transaction ID.
Look for conditions: a race (fast actions), cache, time zone, specific data, load.
Ask the developer to check the server logs by time.
If it still doesn't reproduce, document everything found and the frequency and defer it with monitoring, rather than just closing it.

In an interview: First I reproduce under exactly the same conditions: environment, build, user, data. I collect the logs, the network and the time of the incident, look for special conditions such as a race or a cache, and ask the developer to look at the server logs. If it doesn't reproduce, I document everything found and the frequency instead of just closing it.

The developer says "it's not a bug". What do you do?

First check yourself: what do the requirement, the mockup, the agreement say? Maybe I misunderstood the expected behaviour.

If the requirement is unambiguous, show it and the evidence. If the requirement is ambiguous or silent, the question is not for me or the developer, but for the PM or the product owner: they decide how it must be. I record the outcome in the ticket.

The main thing is to argue about the product's behaviour, not about who is right.

In an interview: First I check myself against the requirement and the mockup. If the requirement is clear, I show it and the evidence. If it is ambiguous, the question goes to the PM, because the expected behaviour is defined by the product, not by me and the developer. I record the decision in the ticket so we don't come back to it a second time.

The bug report and steps to reproduce

Structure: title, environment, preconditions, steps to reproduce, actual result, expected result, severity, priority and attachments. The title answers the question "what, where, under what conditions", for example "Cart: the total isn't updated after removing an item". The environment includes the browser, OS, build version, test environment and test account.

Steps must be numbered, minimal and sufficient for anyone to reproduce the bug the first time. Before writing it is worth reproducing the bug again and discarding extra steps. I always specify concrete test data and the reproduction rate if the bug is intermittent.

Attachments are a screenshot, video, console logs, a HAR file or an API response. One bug is one report, and before creating it I check whether there is a duplicate.

Severity vs priority

Severity is how much a defect affects the system technically; QA determines it. Priority is how urgently it must be fixed from the business's point of view; usually determined by the PO or a manager. These parameters are independent of each other.

High severity, low priority: the application crashes if you enter 1000 characters in a rarely used settings field of an old version of a report. Low severity, high priority: a mistake in the company name or the logo on the home page before a release. High severity and high priority: users can't pay for an order.

Typical severity levels: blocker, critical, major, minor, trivial. Priority usually has the levels high, medium, low or P1–P4.