A bug report has many fields — title, severity, environment, attachments. But three fields sit at the absolute heart of it, and if these three are wrong, nothing else matters. Get the Golden Trio right and you can write bug reports that get fixed quickly, without unnecessary back-and-forth.
Learning Objectives
By the end of this lesson you will be able to:
- Write Steps to Reproduce that are atomic, numbered, and universally repeatable
- Describe the Actual Result in factual, observable terms
- Define the Expected Result based on requirements, not opinion
Steps to Reproduce (STR)
The Steps to Reproduce tell the developer exactly how to witness the bug themselves. If they can't reproduce it, they can't fix it.
The Rules
Atomic steps. Each step should describe one discrete action. "Log in and navigate to settings" is two steps. "1. Open the application. 2. Enter valid credentials and click Login. 3. Click Settings in the navigation." is three steps.
Numbered list. Order matters. Use a numbered list, not bullets.
Complete from scratch. Assume the reader starts from a clean state. Include every precondition: the user account you used, the browser, the data that needs to exist before step 1.
Reproducible by anyone. A developer on a different machine, a QA engineer returning to it six months later, a support engineer in a different country — they should all be able to follow these steps and see the same result.
Before and After
Weak STR:
Go to the login page and try logging in. It crashes.
Strong STR:
Preconditions: Test environment at staging.example.com. User account: test@example.com / Pass1234. Google Chrome 120.
Steps:
- Navigate to
https://staging.example.com/login- Enter email:
test@example.com- Enter password:
Pass12(intentionally 6 characters — below the 8-character minimum)- Click the Login button
Actual Result (AR)
The Actual Result describes what the system did — exactly and factually.
The Rules
Describe behavior, not cause. "The page reloads without displaying a validation error" is correct. "The developer forgot to add validation" is not your call to make in this field.
Observable and specific. "It doesn't work" is not an Actual Result. "The button becomes unresponsive and no action is taken. No error message appears. The network tab shows no outgoing request." is an Actual Result.
No emotional language. "The app completely falls apart" is emotional. "The application throws a 500 Internal Server Error and the session is terminated" is factual.
Example
Actual Result: The Login button is clicked and the page reloads. No validation error is displayed. No network request is visible in the browser's DevTools Network tab.
Expected Result (ER)
The Expected Result describes what should happen, based on the requirements.
The Key Rule
Ground it in the spec. "It should show an error" is an opinion. "Per the acceptance criteria in PROJ-82: 'The form must display the error message Password must be at least 8 characters when fewer than 8 characters are entered.'" is a fact.
Without a requirements reference, a developer can legitimately respond: "That's your opinion, not a requirement." With one, the conversation is much shorter.
Example
Expected Result: Per the acceptance criteria in PROJ-82: the form should display the validation message "Password must be at least 8 characters" when a password shorter than 8 characters is submitted.
Putting It All Together
A complete Golden Trio:
Preconditions:
- Staging environment (staging.example.com, build 2.4.1)
- User: test@example.com
- Browser: Chrome 120 / macOS 14
Steps to Reproduce:
1. Navigate to https://staging.example.com/login
2. Enter email: test@example.com
3. Enter password: Pass12 (6 characters)
4. Click "Login"
Actual Result:
The page reloads without any validation error message.
No network request is visible in DevTools.
Expected Result:
Per PROJ-82 acceptance criteria: the form should display
"Password must be at least 8 characters" and prevent submission.
A developer reading this has everything they need to reproduce, understand, and fix the bug. That is the goal.
Pro Tips
Write the STR immediately after you find the bug. Memory degrades fast. The five minutes you spend writing proper steps now saves 30 minutes of back-and-forth tomorrow.
If you can't write clear STR, you don't fully understand the bug yet. The act of writing forces you to understand. If you struggle to describe the steps, go back and reproduce it again until you can.
Summary
- Steps to Reproduce: atomic, numbered, complete from a clean state, reproducible by anyone.
- Actual Result: factual and observable — what the system did, not why.
- Expected Result: based on documented requirements — not opinion.
- The Golden Trio is the core of every bug report. Get these right and the rest of the report is polish.