SkilsMVP

QA Engineer guide

How to write a bug report

A bad bug report wastes developer time. A great bug report gets the bug fixed faster and makes you look like a pro. Here is the exact format used by QA engineers at professional software teams.

The 8-field bug report format

Every professional bug report has these eight fields. Miss one and the developer either can’t reproduce the bug or has to come back to you with follow-up questions.

  1. 1
    Bug ID:[BUG-001]

    Unique identifier so the team can reference it in Jira, Slack, or code comments.

  2. 2
    Title:[Summary in under 10 words]

    The most-read field. Make it scannable and specific — verb + what broke + where.

  3. 3
    Environment:[Browser, OS, device, app version]

    Developers can't reproduce without this. Always include all four if relevant.

  4. 4
    Severity:[Critical / High / Medium / Low]

    How bad is the impact to the user? Separate from priority (which is a business call).

  5. 5
    Priority:[P1 / P2 / P3 / P4]

    When should this be fixed? Set by the team or PM, often defaults to match severity.

  6. 6
    Steps to reproduce:[Numbered list, exact steps]

    If a developer can't reproduce it, it can't be fixed. Every step matters.

  7. 7
    Expected result:[What should happen]

    What the correct behavior looks like — based on requirements or common sense.

  8. 8
    Actual result:[What actually happened]

    What the user sees instead. Be factual, not evaluative. Describe, don't interpret.

  9. 9
    Screenshot / video:[Always attach if possible]

    Visual proof cuts resolution time dramatically. Annotate the screenshot if helpful.

Severity levels explained

Severity describes the impact on the user, not the urgency of the fix. Priority (P1–P4) is a separate business decision. Getting these right prevents both under-escalating real problems and crying wolf on minor issues.

CriticalApp crashes, data loss, security breach — fix immediately
  • –Payment fails and user is charged but no order is created
  • –User data is exposed to other accounts
  • –App crashes on launch for all users on iOS 17
HighMajor feature broken but a workaround exists
  • –Login button broken on mobile — users can log in via social auth
  • –File upload fails — users can email files as a workaround
  • –Search returns no results — users can browse categories instead
MediumMinor feature broken or UI issue affecting usability
  • –Dropdown menu clips off-screen on mobile viewport
  • –Error message is unclear and users don't know what to do next
  • –Date picker shows wrong month on first open
LowCosmetic issues, minor copy errors, nice-to-fix
  • –Button label says 'Submiting' instead of 'Submitting'
  • –Hover state color is slightly off-brand
  • –Footer copyright year shows 2023

Good bug report vs. bad bug report

The same bug, two different reports. One gets fixed. One sits in the backlog forever.

✕Bad

Login is broken on mobile

What device? Which browser? How do you reproduce it? What does “broken” mean? This report will sit in the backlog until someone asks 4 follow-up questions.

✓Good

Login button unresponsive on iOS Safari 17.2 after entering wrong password

Environment: iPhone 14, iOS 17.2, Safari

Severity: High

Steps:

  1. Open app on iOS Safari
  2. Enter incorrect password
  3. Tap ‘Try again’
  4. Enter correct credentials
  5. Tap Login

Expected: User logs in successfully

Actual: Login button does not respond to tap. Must hard refresh to proceed.

Bug report titles that work

The title is the most-read field. A weak title gets the bug misrouted or deprioritized. Use this four-part formula every time.

Formula

What brokeLogin button+Whereon iOS Safari+Whenafter entering wrong password+What happens insteadbutton does not respond to tap

Result:

“Add to cart button disappears on product page when user scrolls past 50% on mobile”

Practice exercise

Reading about bug reports is not the same as writing them. Do this exercise now.

  1. Open any website you use regularly — could be your bank, a news site, an e-commerce store.
  2. Find 3 real usability issues. They don’t have to be crashes — look for things that are confusing, broken, slow, or inconsistent. Buttons that are hard to tap, error messages that don’t explain anything, forms that lose your input.
  3. Write a proper bug report for each one using all 8 fields above. Include the exact steps you took, what you expected, and what you saw instead.

This is exactly what QA engineers do in take-home assessments. Doing it unprompted on a real site — and sharing those reports in an interview — is one of the strongest signals a junior QA candidate can send.

Next steps

Practice QA skills

Bug reports are one skill in a QA engineer’s toolkit. Explore the full role guide and hands-on challenges to build the rest.

QA Engineer role guidePractice challenges