How I test Games

If you want a career as a Tester, this is for You

I don't test computer games, well, I do, but I'm not paid to. I will hopefully never work in a game software house, but it's not a bad way to start at all. I decided testing games was not for me after a interview at Sony in London. 

In a gray part of London in 2006 (much of London is gray looking once the heat of summer kicks in mind-you), I went to a round building, full of kids. Don't get me wrong, I've been to the Jagex (Runescape) HQ too and those kids are having the same kind of fun, but the pay. So yeah, not for the pay and the hours at all, but I do test games. I started writing games reviews over 3 years ago. and that has attracted attention from small indies who want to get positive reviews written around the time of their launches. Pushing the socials kind of stuff, so they often send out free pre-release copies. When I get a copy I write a review, but I also give defect feedback for any that are in beta, and here is gets tricky.

Games are easy to test and a good start for learning for to file defect reports.

How to write a bug report without any requirements

Well, you do have 2 requirements, the game has to be "playable" and has to make someone money eventually. 

Requirement #3 You have the game description, so when reporting an issue with the game, you want to see where the game description deviates from what your experience is. If the game is aimed at children, it has to use suitable language. Not too cutesy, because kids know when they are being spoken down to, but not too adulty, or else mum won't let her 7 year old play the game. So the smallest bugs you can raise are for things like grammar and spelling, and believe me, these are really easy to screenshot and get corrected. Easy bugs also help you get the developers attention. build relationship, ask them questions about what they hope the game will become or do. And be genuine but kind and build connection. In a real job, bugs are not just a thing you write up once and forget, they are a conversation than can go back and forth. In the industry we call it "bug tennis", where an issue goes back to you because you left out something or explained it poorly. This costs time.

What

Where/When

Why

1. Think small, but think big.

The best time to write a well supported bug for a computer game, is when the code is still very changeable. It's amazing how badly architected games code can be and how hard to change it often can be. Games are usually monolithic and not component-based at all. They are supposed to do one thing, and not have components that make any code changes easy to do in the way applications might be modified. So any suggestions that require a big change are usually far more work than you think.

Above is a screenshot of a game on the left with my suggested "accessibility" change on the right as a mocked up image, to make the text pop more. There are other issues in this screenshot, and my version on the right is not perfect, but it's a 5 minute defect. Always describe what you "expected" things to end up in your bug report. Not what you wanted to happen.

2. Smol QOL changes, bigger wins.

QOL (Quality Of Life) are one step bigger than the smaller (SMOL #slang) cosmetic bugs like fixing spelling, fixing the colour of something or the positioning of something. I see a lot of games get bad reviews not based on the enjoyability of the game, but on it's playability. For example any interaction menu like when clicking on something or responding to an event the user has to perform a repetitive mouse gesture or series of clicks. These break immersion because they waste time. Gamers call these QOL issues.

3. Classification

When writing a bug report, don't write like people do on the forums, come up with a classification system that makes sense for the product, and use the class of defect in the defect title. This will grab a developers attention when they are fishing for defects to fix in the backlog tool whatever that might be. good defect titles make you not only write a good bug report, but also mean you bug will get seen if at all in the flood of emails a developer might see.

I prefer to spend a minute and write a one liner bug title before I start writing up the bug itself. Bug titles should fit in one line in your screen. Example:

"Cosmetic: When catching a butterfly the camera briefly goes fuzzy"

Now this bug might not be a simple one to fix in the end, but it's not a critical bug like a crash or other data loss bug. Hangs, Crashes, Data loss, all of these are what we sometimes call showstoppers. which brings me to another point about bug reports.

Having a good bug title/description will also force you to write the bug report about one item and one issue only. Never lump 2 bugs into one unless they are tightly related.

4. Priority versus risk

Do not ever try to give a bug priority, that is the product owner's job. Lots of the bugs you report will never be fixed, often because the issue you found does not really impact the core mission. Or worse is a hard to reproduce defect, or just a defect that does not do much damage to the end quality. People who post on forums have a habit of making their complaint about a game or an app, the most important. They forget that 90% of people playing the game will not ever notice the thing that they do. Yes, most bugs, tend to only impact a very small number of users. The ones that impact all users are ones that tend to get fixed. Given the choice of 2 defects I might find, I'm always going to raise the one that will impact more. So the tester's job is to describe the impact or risk of a bug impacting a user, not it's priority in the work queue.

Finally: Screenshots Screenshots Screenshots

Before you hit send on your beautiful bug description make sure you have evidence, and are laying out your bug report with the 3 key elements. What, where/when and Why.

I love testing all kinds of software, and hope to improve my written communication, so expect to see more of these. Let me know in the comments are you a paid games tester, I really would love to hear from you.