“Every choice leads to a different result. That’s the way the world works.” – Makise Kurisu

_{Just like Kurisu says in Steins;Gate, the steps you take matter — especially when you’re trying to reproduce a bug.}

Welcome back to QA Basics in game development!

In today’s post, we’re tackling Reproduction Steps!

Sorry PlayStation, and all the “Steps to Reproduce” loyalists—I was one of you from 2008 to 2023. Then I discovered the rest of the QA community and jumped ship. “Reproduction Steps” is just cleaner. Can’t argue with that. Don’t even try.

We covered some Reproduction Step formatting in the last post on writing clear bug Descriptions, so if you missed it, that’s a good place to start. (Pt.3).

The same formatting rules still apply: ‘Single Quotes’, “Double Quotes”, Capitalisation, and [Square Brackets].

In this post, we’ll dive into what Reproduction Steps actually are, some extra formatting tips, and what you should be keeping in mind as you write them.

Reproduction Steps

Reproduction Steps are a numbered list of actions that a tester or user can follow to trigger an issue again. It sounds simple, but damn—this is where a lot of people trip up. Mainly due to the fact that it has to be easy to follow whilst also including all imperative details.

Here are my rules on how to do that:

1. Bugs should only have ONE set of Reproduction Steps.
2. Reproduction Steps should only define ONE route.
3. Choices within the route should be delimited with “>”.
4. Options within a choice should be delimited with “/”.

Why those Rules?

Bugs should only have one set of Reproduction Steps for one main reason: like every other part of a bug, they need to be clear and concise. If someone on the dev team wants to reproduce it or verify a fix, one clean set of steps reduces the risk of misinterpretation.

You can include other possible paths in the Description or Notes, but ideally, a well-researched bug will give you one clear, repeatable route. If you find yourself needing more than one set, you’ve either got multiple bugs—or you haven’t nailed down the root cause yet. That’s your cue to keep investigating.

In regards to “Reproduction Steps should only define ONE route”, this where you can have some leeway in leaning on your Description or Notes. For example, if the following steps caused the application to crash when selecting ‘Settings’:

1. Boot the application.
2. Select ‘Story Mode’ > ‘Slot 1’/’Slot 2’/’Slot 3’ > ‘World 1’ > ‘GO!’.
3. Once in gameplay, press [Options button].
4. Select ‘Settings’.

But if it also crashes in ‘Multiplayer Mode’, which involves lobbies and matchmaking (i.e. a whole different route but the same bug), that’s when you drop a line in the Notes like:
“This issue also occurs in Multiplayer Mode.”

You can also see the other two rules in use in the example steps. I have seen the above steps written like this:

1. Boot the application.
2. Select ‘Story Mode’.
3. Select either ‘Slot 1’ or ‘Slot 2’ or ‘Slot 3’.
4. Select ‘World 1’.
5. Select ‘GO!’.
6. Progress to gameplay.
7. Press [Options button].
8. Select ‘Settings’.

Don’t even get me started on what those steps could look like without the quotes and brackets! It’s like watching a clear report slowly drown in its own words.

Hopefully, it’s pretty apparent what the “>” and “/” are for here. They really condense the information without losing any of it and I don’t know about you but the quicker I can read something, the better!

It can be tricky learning where to use the delimiters and where to use a new step.

Rule of thumb: If the next action is an obvious on-screen option (and uses an interaction the user already knows), use “>”. If you’re introducing a new interaction or asking them to observe something new, use a new step.

One last tip: write Reproduction Steps like they’re for a new user.

Don’t assume the person trying to reproduce the bug knows the app as well as you do—they might be a dev seeing a feature for the first time during a call.

Don’t spoon-feed, but don’t assume they have your context either.

---

Final Thoughts

As I mentioned earlier, Reproduction Steps might seem straightforward, but they’re where even experienced testers can stumble. Over the years, I’ve tested out loads of ways to write and refine these steps, and I’ve landed on something that’s fast, readable, and makes sure bugs can actually be reproduced—which is kind of the whole point, right?

Next week, we’ll be diving into the Notes section of a bug—where all those juicy extras and edge-case mentions belong (instead of cramming them into your Repro Steps).

As always, drop me a message or leave a comment if this helped, or if you’ve got your own tricks for keeping Reproduction Steps tidy and bulletproof. Would love to hear how this one landed with the QA crowd!