A bug report only helps if the developer can make the problem happen on their own device. Saying “The app is broken” or “it crashed again” does not give them enough information. A clear report can save days of back-and-forth and lead to a quick fix.
This guide is for testers, product managers, support agents, and users helping with a beta. It explains exactly what to include in a bug report.
Why most bug reports fail
Most bug reports do not work because they describe how something felt instead of what happened step by step. Developers need to see the same problem on their own device. To do that, they need to know what you did, what you expected, what actually happened, and what device you used. If any of these are missing, the result is often “cannot reproduce” and a closed ticket.
Step 1: Write a specific title
The title should say what the problem is, where it happens, and what causes it, all in one line. Here are two examples:
• Weak: Checkout broken
• Strong: App freezes on payment screen after tapping Apply Coupon
A clear and specific title helps the team find duplicate reports and decide what to fix first.
Step 2: List the steps to reproduce
List each action in order, starting from opening the app until you see the bug. Do not leave out steps, even if they seem obvious. For example:
1. Open the app and log in with a test account.
2. Add any item to the cart.
3. Go to the payment screen.
4. Enter the code SAVE10 and tap Apply Coupon.
5. Wait about five seconds.
After that, repeat the steps. Write down if the bug happens every time, only sometimes, or just once. For example, “3 out of 5 attempts” is much more helpful than just saying “sometimes”.
Step 3: Describe expected versus actual results
Write what you expected to happen and what actually happened. Keep each answer to one short sentence.
• Expected: The discount is applied and the total updates.
• Actual: The screen stops responding, and a few seconds later the app shows a message saying it is not responding.
Step 4: Add device and app details
Some bugs only happen on certain phones or versions, so always include these details:
• Phone model and manufacturer
• Operating system version
• App version and build number (usually under Settings or About)
• Network type: Wi-Fi, mobile data or weak signal
• Language and region settings, if relevant
• Whether you were logged in, and with what type of account
Step 5: Attach screenshots or a screen recording
A screenshot or video makes things clearer. Take a screenshot of the error or record your screen as you repeat the steps. Most phones have a built-in screen recorder. Before you share, blur or crop out any personal details like names, email addresses, or card numbers.
An example of a complete bug report, with the fields developers rely on most.
Step 6: Note the time and include logs if you can
Logs help developers see what the app was doing in the background. If you are using a test or beta version, look for a “send logs” or “share diagnostics” button. If the app crashed or froze, write down the exact time it happened and your time zone. This helps developers match your report to their crash logs and see what was happening on your device just before the problem.
Step 7: Explain the impact
Developers fix the most serious bugs first, so explain how much this bug matters. Does it stop a purchase, sign-up, or main feature? Is there a way around it, like restarting the app or switching to Wi-Fi? Are other users seeing the same problem? A short note like “blocks checkout, no workaround, three customers affected today” helps the team decide if it needs a quick fix or can wait for the next release.
Use in-app reporting when it is available
Many apps now let you report a problem from inside the app, often by shaking your phone or tapping “Report a problem”. Use this feature whenever possible. In-app reporting usually adds a screenshot, device details, app version, and recent activity for you. This covers most of the checklist with one tap. Teams that use a bug report app or in-app reporting tool get these reports linked to your session, which helps them fix issues faster.
A simple template you can copy
Use this structure for every report:
• Title: problem, location and trigger
• Steps to reproduce: numbered, from app launch
• Expected result: what should happen
• Actual result: what happened instead
• Frequency: for example, 3 out of 5 attempts
• Environment: phone, OS version, app version, network
• Attachments: screenshots, recording, time of the crash
Final tips
• Report one bug per ticket. Mixing issues makes tracking harder.
• Search existing reports first to avoid duplicates.
• Stay factual. Describe what happened, not who might be at fault.
• Reply quickly if a developer asks a follow-up question.
A good bug report respects everyone’s time. It gives developers a clear path to the problem and gets the fix to users sooner.
