“We are not just fighting vampires; we’re fighting ignorance, bureaucracy, and evil. The last two are often the same thing.” – Rupert Giles

Organised Chaos Freedom

Games are — arguably — the most creative form of expression. They blend art, storytelling, music, and poetry. But they also introduce something no other art form quite matches: systems.

Gameplay systems can evoke emotion purely through interaction. And like any creative work, there’s no single “correct” way to build or experience them.

And yet… we have to test them.

If you’ve read my earlier posts, you know I come from a platform compliance QA background. That world runs on clearly defined rules, Test Cases, that must be passed for a game to be released on a platform. Yet despite the rigidity, these same rules manage to support an incredibly diverse range of games.

Requirements are organised and well defined but can be applied to any game. There’s structure, but room for interpretation.
And honestly?
I like that.

When I joined an indie studio and started working on original IPs, I expected something similar. But what I found was… different. Testing was performed against the G.D.D. and there’s a new G.D.D. for every project. So I started reading up on functionality Test Cases and I almost couldn’t believe what I saw. A lot of the time, examples were strict Test Scripts with steps that had to be followed to a tee, allowing for very little flexilibty. A Test Case for every path and every outcome.

I do not like that.

There had to be a way that didn’t require new Test Cases for every G.D.D.

So here we are, ready to explore how I create and organise my Test Cases, Suites, Scripts and Methods.
How I create requirement style organisation and freedom for functionality testing.

Starting From Scratch

When I started, I knew my end goal was to have a document containing all of my Test Cases that I could transfer between projects with little, or possibly any, adaption. My plan to get there required leaning on experience and a knowledge of how things usually function alongside the G.D.D., and a way to categorise.

I began testing armed solely with those three tools. I bugged issues that deviated from well know practices or the G.D.D. and I labelled all of them in Jira. To begin with, it was pretty chaotic, with no real clear categories the labels were very varied.

But no game is ever short of bugs and soon enough, patterns started to emerge, labels became more structured. Here’s the structure I ended up with:

🔹 QA-Gen_Suite
🔹 QA-Feat_Suite
🔹 QA-Requirement
🔹 QA-Debug

That last two are propbably quite obvious, “QA-Requirement” is a labelled attached to bugs that may result in a platform compliance failure and “QA-Debug” is a labelled attached to bugs in features that are required for test but not for end users.

The other two labels I’ll explain.

Feature Suites

As I started building the bug database, pretty much every bug had a “QA-Feat_” label. Everything was a feature specific in a game and so we ended up with labels like:

QA-Feat_Wheels
QA-Feat_FirstPerson
QA-Feat_Level
QA-Feat_MainMenu

I’m sure you can imagine that over the course of several projects, there were a lot of bugs and a lot of labels! Also, bugs would usually have a couple of labels as I has yet to create more defined suites.

But at the end of one project, we categorised them all. It took a few days and as we started clumping together similar labelleds, we could start defining our real goal. Generic Suites.

---

A New Series Begins!

Over the next few posts, I’ll walk you through how we distilled dozens of individual feature tags into a handful of Generic Test Suites — reusable across games, flexible yet structured!

Then we can start to dig into how to create the Test Cases for our Feature and Generic Suites.

Let me know how your structure and define your Test Cases, I look forward to seeing other perspectives and sharing my methods over the next few posts.

Take it easy, QA Adventurers!