Gaming: The King of Testing

Every kind of software is hard to test in its own way. Games are hard in every way at once. This is the arena where testing is at its most fun and its most brutal, and for decades it is the one place automation could never really follow. That is finally changing, and we think games are about to go from the hardest thing to automate to the most valuable place to do it.

A short history of a quality problem

Games learned the cost of bad quality the hard way. In 1983, the North American game market collapsed. Stores were flooded with shovelware, players stopped trusting that a cartridge was worth buying, and the industry nearly wiped itself out. When Nintendo rebuilt the market a couple of years later, it did it partly on the back of a promise: the Seal of Quality, a little gold badge that told you someone had actually checked the thing before it reached your living room. Quality was not a nice-to-have in games. It was the whole business.

So the industry did the only thing it could. It hired people to play. Rooms full of testers running the same level hundreds of times, taking notes, trying to walk through walls, mashing buttons in orders no sane person would, living through crunch before every launch. Decades later most game QA still looks like this. It is skilled, exhausting, human work, and it is the reason your favorite game shipped without falling apart.

Meanwhile, the rest of the software world quietly automated its testing. So why did games get left behind?

Why automation skipped gaming

Think about testing a normal web app. The screen is built out of labeled parts. There is a button with a name, a form with fields, a page with a structure underneath it. A test can reach in and say "find the submit button, click it, check the result." It is like giving someone directions on a fixed street grid. The streets do not move.

Now try that in a game. There is no button with a name. There is a character, a physics engine, particle effects, an enemy that reacts differently every time, a world that may be generated on the fly, and a screen that is redrawn from scratch sixty times a second. Nothing sits still long enough to grab onto. Two playthroughs of the same thirty seconds are never identical. The input is not a click, it is an analog stick held at a precise angle for a precise fraction of a second. Automating a web app is directions on a street grid. Automating a game is giving directions in a world where the streets rearrange themselves and the weather changes while you talk.

That is the wall traditional automation hit. You cannot script your way through a world that refuses to hold still. So games stayed manual, not because studios did not want automation, but because the tools had nothing to hold onto.

Why now is different

There have been famous moments where AI conquered a game. In 2019 OpenAI Five beat the Dota 2 world champions, and DeepMind's AlphaStar reached Grandmaster level in StarCraft II. Incredible achievements, but look at what they actually were: one system, trained for enormous cost, on one game, to win at it. That system could play. It could not test, and it knew nothing about any game but its own.

The shift that matters now is real, but it is easy to oversell, so let us be precise. On their own, today's general models can look at a screen and make sense of what is on it, and that is genuinely new. Point one at a simple, slow game and it can play. Point it at a real game, something fast, reactive, and unforgiving, and it falls apart. Three things break it. Latency, because a model that pauses to think for a second has already missed the moment in a game running sixty frames a second. Accuracy, because reading a chaotic screen correctly most of the time is not the same as reading it correctly every single time. And stability, because a run that works once has to work the ten thousandth time too.

This is the real problem, and it is not one you solve by sitting around waiting for a bigger model. We solve it with pure algorithms wrapped around the model. The model is Batman: the one with the instincts, the read on the room, the understanding of what is actually happening on the screen. We are Robin: the partner who makes sure the plan holds up when everything is moving fast. The model brings the understanding. Our algorithms give it the speed, the precision, and the consistency to use that understanding inside a real, live game. That combination is the thing that was missing for forty years.

The part we are most excited about

Here is where it stops being about testing and starts being about something bigger.

An AI that tests a game has to play the game. And to play it well, it has to build a model of how the game works: what leads to what, which action opens which door, where the walls are, how a level flows from start to finish. In other words, the act of testing produces a working simulation of the game as a side effect. The agent becomes a simulator.

Keep going and it becomes the knowledge base of the game. Every session it runs, every workflow it walks, every state it passes through gets recorded as structured data. The more it plays, the more it knows, and the smarter every future run becomes. That is a flywheel, not a one-time script. Out of that data you can build action models, a real map of what can be done in the game and what happens when you do it.

And this is where it solves a problem that has quietly frustrated everyone working with AI. Language models are not that good at intent (Yet). You describe what you want, you get something close, you rephrase, you try again, and after five or ten iterations you finally land on what you meant in the first place.

That is the real prize, the next generation of workflow operators won't be defined by automation alone. They'll be defined by how well they can train, guide, and shape AI models into dependable operators. Consistency, speed, reasoning, and eventually even behavioral profiles that mimic different types of users will become the real differentiators. I'll dive deeper into that in a future article.

Where Duzz comes in

This is exactly what we are building. Duzz plays your game the way a user does, and while it plays it builds a living, structured understanding of how your game actually works. That understanding is what makes the testing reliable, and it is also what turns your game into something you can query, simulate, and build on. We think the studios that treat this as core infrastructure, and not just as a faster QA line, are going to have an unfair advantage.

Games were the final boss of test automation for a long time. We started Duzz because we think that boss is finally beatable, and that beating it unlocks a lot more than a passed test suite. If you build games and this is on your mind, we would love to talk.