Before you write, check it is new
A second ticket for the same bug splits the conversation and wastes the time of whoever picks up the copy. Search the tracker with the error text, the screen name and a word or two from the symptom before you start. Catch duplicate bugs before you file them explains why duplicates happen, and the duplicate search cheat sheet gives searches you can paste into Jira, GitHub and Azure DevOps.
Write a title that names the problem
The title is what people scan in a list, so it should say what broke, where, and under what condition: "Checkout total ignores the discount code on mobile Safari" tells a developer more than "Checkout broken". Keep opinions and urgency out of it; severity has its own field.
Write steps someone else can follow
Reproduction steps are the heart of the report. Start from a known place, number each action, include the exact data you typed, and stop at the moment it fails. How to write reproduction steps has a checklist and a before and after example, and the free steps to reproduce checklist gives you a template to fill in.
Say what you expected and what happened
Write the two side by side. "Expected: the total drops by 10%. Actual: the total stays the same and no error appears." The gap between them is the bug, and writing it down makes it hard to misread.
Add the environment and the evidence
Name the version or build, the device, the browser or OS, and the account type. Then attach what shows the failure: a cropped screenshot or a short recording, and the part of the log around the failing moment. Reproduce a bug from a log file shows how to find that moment and trim the rest. Keep passwords, tokens and personal data out of everything you attach.
When the bug is hard to pin down
Some bugs do not appear on every run. Count your attempts, note what changes between them, and say so in the report: how to report a bug that only happens sometimes. If something that used to work has stopped, find the last version that worked and the first that failed: how to report a regression.
Set severity and priority
Severity is how bad the failure is; priority is how soon the team should fix it. They are separate decisions, often made by different people. Severity vs priority has a matrix with examples, the bug triage checklist keeps the triage meeting short, and the free bug severity helper suggests a severity with a reason you can paste into the ticket.
Use a template for your tracker
A template makes reports arrive with the same parts in the same place. A bug report template developers will actually read explains each part, the tracker templates give a version for Jira, GitHub Issues and Azure DevOps, and the good and bad examples show weak reports rewritten. The free bug report template builder lays a report out for Jira or Azure DevOps, and the free template pack has these templates as files to download.
The short version
Check it is new, name the problem in the title, write steps a stranger can follow, say what you expected and what happened, attach the evidence without personal data, and set severity and priority as two separate calls.
Where BugIt fits
BugIt writes a report with these parts filled in from a rough note, checks it, and files it to your tracker after you type FILE IT. See how it works at bugit.dev or read about it at taskivator.com/bugit.