Welcome back to QA Basics in game development!
Bug writing basics are done! You know all you need to know!
Bug Writing Isn’t That Simple
I covered what I believe are the crucial components and key rules for writing bugs but there’s always challenging bugs out there that will test that structure. More often than you’d like to think too, it’s pretty much par for the course. I’ve been writing bugs for 18 years, and over time I’ve developed a flexible format that can adapt to tricky scenarios while still keeping the structure teams expect and appreciate. You may be right at the beginning of your QA career (I hope you enjoy it as much as I do!!) and I think these rules will help you answer some pretty directed questions in interviews and get you started in your first role but landing that first role can be the biggest of all challenges. Honestly, I wish everyone out there looking for their role the absolute best of luck.
In the next post, we’ll be getting back to the “Submissions to Sprints” vein and talking about some new approached I’ve had to develop to meet challenges I’ve faced so to wrap up this 1st QA Basics series (oh yes, there will be more) I’m going to give a few pointers on how to prep for bug format questions in an interview and finally give an example of a badly written “lengthy” bug being condensed into a sweet chef’s kiss of a bug.
Interview Questions About Bugs
Game development is always progressing with new tools and so interview questions change all the time. If you have yet to land a QA role, my number one piece of advice would be to stay up-to-date with the latest game development tools, watch videos from GDC talks and other conferences and whatever of source of game dev info you can get your hands on. Join your local Game Dev network if you can! Attend meetups, or connect online — staying current is your best weapon. Do that and think about how you can use the bug components I’ve described to facilitate a dev team member in debugging an issue. Practicing writing bugs is great but you can step up your game if you know how the latest tools work and you can tailor your bugs to them.
My next piece of advice, which although isn’t as accessible, is very powerful. Complete a simple Unity/Unreal game dev tutorial. It may seem daunting to try something like this on your own but it will be a huge bonus to landing a role in a smaller and more Agile based dev team.
Try either of both of those and then prepare yourself for questions like:
- What’s the difference between Priority, Impact and/or Severity?
- What are best practices for writing bug reports?
- If a dev can’t reproduce your bug, what should you do?
Hopefully 1 & 2 sould be simple enough now that you’ve read these blog posts but question 3 is a popular one and it’s an opportunity for you to show you know about the tools a dev team uses and the type of working environment you would like to create, for example:
Serious Interviewer Person: “If a dev can’t reproduce your bug, what should you do?”
Cool Future QA Tester: “Firstly I would talk to the dev and try to find potential misunderstandings with my formatting. It could be a because of an issue in naming conventions used in my bug and the Unity Inspector, so I’d need to make sure they’re aligned and if that was the case, I’d ask for advice on how to word it better in future. If it they were attempting to reproduce it in editor, I’d make sure my Reproduction Steps make it clear that they should be booting the application as a standalone build. If they’re still not able to reproduce it, I would, if I hadn’t already, add logs, videos etc. Whatever they needed, I’d make sure that they know I’m there to support them and their work!”
The Lengthy Bug
We’re going to put everything to the test here and believe me, this example is not an exaggeration, I’ve seen lots of testers start off writing bugs like this:
Summary
Career progress is sometimes lost after playing offline and then reconnecting to the internet
Description
There’s an issue with how the game handles career save data when switching between offline and online play. It’s inconsistent and too random to determind the root cause. Three testers noticed that sometimes career progress resets when the cloud save system is used.
From what I’ve seen, if a user starts a career while offline and then later reconnects to the internet, the local save gets synced to the cloud. But if they then play offline again and progress the career in a different way, when they next reconnect to the internet, their newer offline progress is overwritten and replaced with the older cloud version from the first time they connected. There’s no warning or message — the player just loads into their old progress.
However, this doesn’t happen if you start the career online. In that case, you can keep playing offline and the local save continues from where the online one left off.
It also doesn’t seem to happen if the user stays completely offline or completely online throughout their whole session. The issue only comes up when there’s switching between online/offline with a career that started offline.
Different testers had slightly different outcomes — one of us lost progress, another didn’t, and I had it happen once and then couldn’t get it to happen again for a while. It likely depends on exactly when the console is connected to the internet and what state the save data is in, but we could not fully check due to time constraints.
Reproduction Steps
- Disconnect the system from the internet.
- Boot the application.
- Start a new career and complete an arbitary amount of races.
- After an auto-save, return to the Main Menu.
- Connect to the internet, load the career and complete a race to trigger an auto-save.
- Return to the Main Menu and disconnect the system from the internet.
- Re-enter the career and observe the current state of progress.
- Complete an arbitary amount of races.
- After an auto-save, return to the Main Menu.
- Connect to the internet, load the career and observe the current state of progress.
Expected Behaviour
The application should either keep the latest progression regardless of source (cloud/local) or prompt the player to confirm which save to use when switching connection states.
Notes
This issue is difficult to reproduce.
Frequency
Random
The Tamed Lengthy Bug
I’d feel bad for the poor junior tester that got handed the test notes to write that bug up with but I made them up, so I don’t.
Lengthy bugs mostly come about from a lack of confidence. A lack of confidence in ability to concisely describe an issue without losing important information, a lack of confidence in being able to put a 100% stamp on it.
But all the info was there, the bug was on the tip of their imaginary tongue! Here’s how I would vet that bug:
Summary
[PC][Epic][SaveData][Career] Cloud Save Data deletes exsiting local Save Data
Description
When a user makes inital progress with their system offline and creates local save data, then if they ever attempt to make progress with their system online, the local save data will be deleted at the point cloud save data it created.
This results in the user being required to start their ‘Career’ from the beginning when they next attempt to play offline.
Reproduction Steps
- Disconnect from the internet > Boot the application.
- Create a new ‘Career’ > Complete a race > Observe the ‘Auto-Save’ message.
- Return to the Main Menu > Connect to the internet > Load the ‘Career’ created in Step 2.
- Complete a race > Observe the ‘Auto-Save’ message > Return to the Main Menu.
- Disconnect from the internet > Load the ‘Career’ created in Step 2.
Expected Behaviour
- Local save data is created in tandem with cloud save data.
- Local save data is not deleted without warning.
Notes
Please note that this issue does not occur if the user stays offline for the entire ‘Career’.
Similarly, that this issue does not occur if the user stays online for the entire ‘Career’.
Additionally, starting the ‘Career’ online and then going offline will cause save data to function as expected initially, however subsequent cycles of online/offline play with the same ‘Career’ will cause the issue to occur as described.
Frequency
PC [10/10]
Lengthy Bug Summary
I hope that, with all your new QA bug formatting knowledge, you were able to see how that big Description was boiled down to its root cause and the important and contextual information was redistributed to the other sections. It’s all important information but contextual stuff can “dilute” or “cloud” your attempt at explaining a root cause in the Description if you don’t keep it under control.
Learning how to find and concisely define a root cause, and learning how to prioritise bits of context, takes experience and hopefully this formatting guide gives you some tools to help put any experience you get to good use.
Final Thoughts
And that’s a wrap on QA Basics – Bug Writing!
I hope you’ve picked up some useful insights — whether you’re just starting out or you’ve been in the trenches for years. Game development has so much depth and variety, and that’s what makes QA a career worth sticking with (at least for me!). There’s always more to learn, more to share, and more ways to grow.
Actually — a final thought popped into my head that might help explain why I’ve stretched bug basics across six posts (so bear with me 😄):
When you join a QA team, especially early in your career, chances are you’ll be surrounded by other testers. Everyone’s finding bugs — and that’s great. But finding bugs isn’t the be-all and end-all of QA work, because the bugs already exist. It’s the Test Plan that brings them to the surface.
What really helps you stand out is not just finding bugs, but being able to clearly and effectively articulate them. That’s the first rung on the ladder. The better you can communicate what you’ve found, the more value you bring to the team.
Stop measuring your value by how many bugs you find — and start measuring it by how often your Lead turns to you for answers!
Next week (hopefully…😅) we’ll be back on to some more project organisation stuff. Application Health!
Looking forward to seeing you there. Peace!
Cayne's QA Blog 
Leave a comment