Chapter 4: How to write clear and efficient steps to reproduce in your bug report
The steps to reproduce is the path any other user has to follow to experience the same bug you did.
It’s maybe stating the obvious but it will be hard to write the right steps if you didn’t really understand the bug and what are the conditions that make it happen.
1. Identify the conditions of the bug
Conditions are diverse and may affect the bug appearance.
- type of user = WHO is experiencing the bug? Is it the end-user? Another role (moderator, admin, super-admin)? A specific end-user? Is this user in a specific status (pending for example)? Is he related to an action with a specific status (delivery in progress for example)? Has the location of the user an influence on the way the product is supposed to work?
- environment = WHERE is the bug? Is it on the website? The mobile App? Is it on a staging or development environment? Is it on the production environment?
- page = WHERE precisely is the bug? Is it on the home page? The splash screen? On the side menu? On Profile? On Cart? Which page/flow/path in particular is impacted?
- medium = WHICH TYPE of DEVICE? Is it a mobile? a tablet? a computer? Another device? A browser ?
- action = WHAT were you doing when you found the bug? Or before finding the bug ?
- Any other parameter specific to the product and could have impact on the observed behaviour.
In industrial quality process, we call this method of defect-finding the Fishbone Diagram (or Ishikawa diagram).
Basically, if you analyse your problem investigating the 5Ms you’ll find the conditions that generates the defect.
2. Provide the mandatory information
Conventionally some information is considered as mandatory when describing the steps to reproduce. On WE ARE TESTERS, we request:
- the URL where the bug is located (or the closest page if it’s a dynamic bug). Failing that (on mobile/tablet apps), the name of the page or anyway to identify where to go.
- the user data set: either login/password (if it’s a fake user set) or only the user login (if it’s a real user) or a role if the visitors is granted some rights.
On WE ARE TESTERS, here is where you have to report the steps to reproduce the bug:
Advices
- Split the steps into several lines
On our tool, you can (and you have to) write one step per line.
One line = one action. - Reduce the number of steps to the essential ones. Save your time and the product manager’s/developer’s by only writing the quickest way to experience the bug.
- Order them logically: Tighten the net, step by step
#TipOfTheDay: to add a line of steps with your keyboard, hit “Enter” key.
Examples
Find some bad examples of steps to reproduce below and the right way to write them.
Bad examples #1:
Step1: Enter valid email address in the Newsletter field on the footer then click on “send”
Good way to write #1:
1/ as a non-logged in visitor, access homepage: http://mywebsite.com
2/ go to footer
3/ on Newsletter field, enter a valid email address
4/click on “send”
5/observe you have to log in
Why is it better?
- The URL is present => it indicates the website, the page and the environment of the test
- the user role is identified => non-logged in visitor
- the medium is not mentioned but the steps would not be altered by the device.
- the logical order : “Enter a valid email address” is not the first action a user has to do to spot the bug =>before you need to go to the footer.
Bad example #2:
Step1: go to the home page
Step2: hover on “info & contact” in the menu
Step3: click on LABEL
Step4: observe main title
Good way to write #2:
1/ access : http://mywebsite.com/info-contact/label
2/ observe main title
Why is it better?
Explaining how to navigate to a web page when the URL is available is a loss of time. Go straight to the point as much as you can. It will save everybody’s time.
Bad example #3:
Step1: open http://mywebsite.com/page1
Step2: observe the field is now empty whereas it was filled in before
Step3: I was logged in with USER1
Good way to write #3:
1/ go to http://mywebsite.com/page1
2/ log in as USER1 : LOGIN / PASSWORD
3/ observe the field is filled in
4/ go to http://mywebsite.com/page2
5/ do action ACTION1
6/ go back to http://mywebsite.com/page1
7/ observe the field is now empty
Why is it better?
Because you introduce the action that generated the bug and you tell the reader how to do it. In the “bad example #3” you only describe the last bit of the steps. Of course you have to dig a bit more into the bug to know exactly what is wrong. But isn’t it the exciting part?
< previous chapter: category — — — — next chapter: devices>
