Portfolios aren’t something you would normally associate with QA roles.

Typically, they’re used to showcase the technical work and experience that someone might want to demonstrate when putting themselves forward for new career opportunities.

However, with QA being a technical and skilled role, it stands to reason that a curated selection of your quality assurance skills might serve to help you on your journey to land a QA role within the games industry.

It’s worth noting that as a gamer, you most likely already possess many of the skills necessary to begin working in QA. If you’ve ever noticed an out of place texture, an animation that doesn’t look quite right, or a spelling mistake in a AAA title, you’re already entering a quality assurance mindset, even if you don’t see it. The question here is how do you harness that, and channel it into a collection of your talent?

Start making projects

It’s a bold first suggestion if you’re somebody who loves the idea of creating your own games, but you’re simultaneously intimidated by the thought of coding or making art. These things are not easy, but the good news is that you’re not going for a programmer or artist job here.

What you’re aiming to do is show that you’re familiar with all the constituent parts of a game, what’s needed to take it from concept to product. Good QA practitioners find themselves aware of what can go wrong at any stage of the development process, and if you have even a surface level understanding of this, you’re giving yourself a stark advantage.

What this practically means for you, is that you don’t need to reinvent the wheel when doing this process. There are endless tools and resources that you can use to address any gaps in your confidence, to make sure you’re able to bring your idea together.

Here are some examples of those resources.

Make a game without programming:

Flowlab.io (free)
Unity, using Bolt (free)
Unreal Engine 4/5, using Blueprints (free)
RPG Playground (freemium)
RPG Maker (paid)
Gamemaker Studio (paid)

Free game art resources:

For these ones, it’s important to check the licensing conditions behind each asset you use. Even if a file is listed as free, it may have conditions for use (i.e, you must give credit, or you can’t use it commercially)

kenney.nl/assets
itch.io/game-assets/free
opengameart.org

Be realistic about your scope

Think of a game you want to make. Simplify it, then simplify it again, and simplify it once more – there, you’ve still probably got more work on your hands than you realise. You aren’t going to be making Skyrim 2 by yourself. You might even struggle to make Snake if this is your first rodeo.

Even if you could, for the purposes of a QA portfolio, this would be overkill, as what we’re trying to do here is prove that you’re aware of how a game gets developed, and everything that can go wrong in that process.

You might find that as you make your simple game, you find yourself focusing on one particular mechanic more than the rest of the game. You might be so focused on it, that you forget to develop the rest of the game and lose wind. This isn’t a bad thing, and all your hard work doesn’t need to go to waste – there are lessons to be learned here, and the knowledge of your development cycle will serve you going forward.

Share your work, reframed as your attempt to implement the mechanic. Work you’ve done is still work, and the development cycle of a single feature is something you’d encounter in a QA job as well.

Log your bugs

Post mortems are famous for being excellent post-project reflections on a game’s development cycle, and they’re not just for big studios. You too can create your own content based around what you did, what you learned, and what you’d do better next time.

When doing so, you’ll want to be succinct and clear where possible. Make sure to focus on problems you faced, how you fixed them, and how you organised your bugs. Bug organisation is important because in any games company, products like JIRA or Azure will be used to keep track of ongoing work and tasks.

Even if you don’t have access to these right now, you can emulate them in something as simple as a Google Sheet. Below is a typical template of what an industry bug report would look like:

Bug title, including tags (Describe the issue succinctly, perhaps including square bracketed tags like [UI] or [Gameplay])
Severity (How likely is this to affect the core functionality of the game? 1 being critical, 5 being very unlikely at all)
Priority (How important is it that this is fixed, and how soon? 1 being immediately, 5 being at some point in the future)
Version number (This bit is critical in a real world setting. Game fixes are often deployed as subsequent versions of the product. A bug might occur in V1.0.1, but be fixed in V1.0.2, for example)
Affected functionality (What specifically does this bug affect? Does it affect player movement? UI? This will be similar to the tags you put in the bug title)
Reproduction rate (Out of x many attempts, how many times could this be reproduced? A good number of attempts is 5)
Reproduction method (Lay out step by step what someone would have to do to replicate what you’ve found. Imagine that the person you’re writing this for has played games, but has not played your game before. Mention things like loading a save, pressing a button etc, but you can skip superficial steps like plugging in a controller, inserting a disk, unless those are key steps to the bug you’re reporting)
Expected result (in an ideal world, what should be happening when you follow the repro steps?)
Actual result (in the actual world, what is happening when you follow these steps?)

One important thing to mention is that severity and priority might seem similar at first glance,
but are very different in practice. You might find a bug that crashes the game, but you could
only reproduce it one out of ten times – in this case, you would have high severity, low priority.

The same can be true in the opposite effect – you might be using an old logo in the main
menu. This doesn’t affect the game’s performance or playability so it’s low severity, but it’s
high priority because this isn’t something you’d want the game to ship with.

Keeping that in mind, a bug report could look something like the following:

[Systems] [Menu] Exit game button crashes game when 27 keyboards are plugged in
Severity: 1
Priority: 4
Version number: 1.0.1
Affected functionality: Systems
Reproduction rate: 5/5
Reproduction method: 1) Plug in 27 Keyboards 2) Load into the game 3) Pause the game 4) Press exit game button
Expected result: The game should not crash, and should exit to menu
Actual result: The game crashes

The above is a modification of an interview question I had for my first ever QA role. I was given a problem, and asked to write a bug report for it, without being given any kind of template. I’d researched bug reports the day before, so I knew vaguely what was expected.

Getting into the process of writing these reports and showcasing them alongside your work not only shows that you create with defects in mind, but also you take a proactive approach to documenting them. Adding these to a section of your portfolio is a great idea, and knowing how to write them prepares you for interview questions as well.

You might also consider writing a bug report for a game made by the company you’re applying for. Whether or not it’s an actual bug that exists in-game is up to you (if you’re making one up, do mention that it’s hypothetical). But showing a company you’re aware of their work and you can apply your new-found bug writing expertise to their products will help to get you noticed.

It’s worth noting that none of these are guaranteed to be read by the people you’re trying to be hired by, but it’s a fantastic way to set yourself apart and demonstrate how you think should anyone want to question that.

Pick your platform

Now that you’ve got some work to show, you need somewhere to put it. Take advantage of the plethora of free website building and hosting services out there that are rife with templates for you to use. If you’re stuck, have a look at the portfolios of other people in industry, and see if you can match the general style that they go for.

Remember to include videos of your work and not just the downloadable final project – someone looking to hire you may not have the time to download and play your project.

Include the documentation you’ve written from above also. If you’re writing a bug report for a game made by whoever you’re applying to, it’s probably worth including this at the application stage too.

Creating a portfolio will be time consuming, and it still has no guarantee of landing you the job you want. Even so, making one is worth the effort – there’s a distinct lack of QA training or certification for people new to the industry. The more you can do to show you understand how games are made and how to effectively report on defects, the better you’ll do overall.