You run a test case and actual differs from expected. The first reflex is usually:
Bug. Log it.
Wait one beat. A frozen screen may be a bug, or the build may be mid-deployment, the account may have lost permission, the data may be wrong, the network may be dead, or the test case may be older than the requirement. The first job is not opening Jira; it is confirming what you just saw.
Before logging
I usually do a quick check:
- Reproduce it at least once if the conditions allow.
- Compare it with the requirement, acceptance criteria and current design.
- Check that the build, environment, account and test data are correct.
- Check the console, network or logs if I have access and they help narrow it down.
- Search for an existing bug to avoid a duplicate.
You do not need to investigate until you have fixed it for the developer before logging. The point is to remove cheap misunderstandings and collect enough facts for the recipient to start working.
A basic bug report
The template depends on the tool, but it usually needs:
| Field | Question it must answer |
|---|---|
| Title | What is wrong, where, and under what condition? |
| Environment/Build | On which version and environment does the failure appear? |
| Preconditions | What state must exist before reproducing? |
| Steps to Reproduce | What do we do to make the failure appear? |
| Actual Result | What was actually observed? |
| Expected Result | According to the test basis, what should have happened? |
| Evidence | Which screenshot, video, request, response, console output or log supports it? |
| Severity/Priority | How serious is the impact and how urgently does it need handling? |
The tool records the ID, creator and time. Don’t copy things the tool already knows into the Description just to make it longer.
Example
Suppose an active account uses the correct email and password, but clicking Login does not change the page.
Title
[Login] Active user remains on Login page after submitting valid credentialsLogin not working is short, but the developer still has to ask how login was attempted, which account was used and where it failed.
Environment
Environment: Staging
Build: 2026.08.09-rc.3
Browser: Chrome 127 / Windows 11
Account: active user, MFA disabledRecord only what could be relevant. An API bug does not need the screen size if it has no effect.
Steps to Reproduce
- Open the Login page.
- Enter the active account’s email.
- Enter a valid password.
- Click Login.
Actual Result
The button enters a loading state for about one second and then returns to normal.
The user remains on the Login page. POST /sessions returns HTTP 500 with errorId abc-123.Expected Result
A session is created and the user is redirected to /dashboard.Actual is what was observed. “The backend has a null pointer” is not actual if there is no log proving it. Expected should not be written as “must not stay frozen”; state the correct behaviour.
What should you use as evidence?
A screenshot suits a static issue: broken layout, incorrect text or an incorrect displayed state. Video suits timing, animation, redirect or a failure that appears and disappears.
For APIs and web apps, request/response, status code, timestamp, correlation ID and console error are often worth more than a bright red screenshot. Remember to hide tokens, passwords, cookies, personal data and customer information before attaching them.
Evidence proves the failure; it does not replace Steps, Actual or Expected. Throwing a three-minute video over the wall without notes just moves the job of writing the bug report to someone else.
Severity and Priority
- Severity: how seriously the failure or defect affects the product.
- Priority: how urgently the business wants it handled.
They are related, but one does not lock the other.
A bug that crashes the app after 20 hours of continuous operation has high severity, but its priority may not be highest if it is rare and the team is handling a payment error that happens every minute.
A campaign banner with the wrong logo has low functional severity, but if the campaign goes live tomorrow morning its priority may jump to the front.
Who sets which value depends on the workflow. Some teams have testers propose severity and the Product Owner set priority; others triage together. Definitions of Critical, High and P0 are project-specific. Don’t bring an SLA from the internet and use it as international law.
Defect workflow
A simple flow could be:
Status names vary by tool, but the main idea is the same:
- A new bug needs triage.
- A valid bug is assigned or put in the backlog.
- A developer saying it is fixed does not close it automatically.
- The tester or owner runs confirmation testing on the correct build.
- If the failure remains, reopen it with new evidence.
Rejected does not always mean the tester logged something stupid. It may be a duplicate, works as designed, cannot reproduce or a risk the business accepts. The reason matters; closing a ticket with Invalid and making it disappear does not.
Bug reports and the deeper article
This article sets the foundation for the series. I also have a separate article about titles, reproduction, evidence, logs and communication so that the ticket does not turn into a tennis match between developer and tester:
There is some overlap, but one article belongs to the introductory flow and the other focuses on making a report genuinely useful to the team.
Wrap-up
A good bug report does not need elegant prose. It needs to be reproducible, distinguish actual from expected, identify the right build and carry enough evidence without exposing sensitive data.
The next article is about test reports. A bug ticket describes one problem; a test report brings progress, coverage, defects and risk together so someone else can make a decision.
