Running a portal with 56,000 browser games sounds like a testing nightmare. Nobody can play 56,000 games, and nobody should try. Yet our players expect every game they open to load, respond to input, and actually be playable. Here is how we check that at scale, without a QA team the size of a small town.
The problem with manual testing at this scale
A single tester, playing one game every five minutes, eight hours a day, would need more than two years to cover the catalogue once. By then, games would have changed, new ones would have arrived, and the whole exercise would be obsolete. Manual testing does not scale, so we stopped pretending it could.
The insight that changed our approach is that most game failures are not subtle gameplay bugs. They are crude, structural failures: the game file is missing, the embed points at a dead URL, the game loads but never accepts input, or the game only works on desktop and breaks silently on mobile. Those failures are detectable automatically, and they account for the overwhelming majority of player complaints.
The automated checks we actually run
First, every game page gets a load check. We fetch the page, confirm the embed resolves, and confirm the game asset returns a successful response. A missing file is the most common failure in a catalogue this large, usually because a game provider changed a URL without telling anyone.
Second, we run a headless browser check on a sample of games every day, and on every newly added game. The browser loads the game, waits for its canvas or main element to appear, and sends a few synthetic inputs: a click, a keypress, a mouse move. If the game never renders, or never responds, it gets flagged for human review. We do not need to know whether the game is fun. We need to know whether it runs.
Third, we check mobile rendering. A large share of our traffic is on phones, and games built for desktop keyboards can fail completely on touch devices. The mobile check confirms the game fits the viewport and responds to touch input. Games that fail are labelled desktop-only rather than removed, because honesty beats a broken experience.
What automation cannot do
Automation cannot tell you whether a game is good. It cannot tell you whether the controls feel right, whether the difficulty curve is fair, or whether the game is a thin clone of a better one. For that, we rely on player signals: play time, return visits, and reports. A game that loads perfectly but nobody plays twice is a different kind of failure, and it gets handled by curation, not by testing.
Automation also misses intermittent failures: games that work nine times out of ten and break on the tenth, usually because of an ad or a third-party script loading slowly. For those, we rely on player reports, and we treat a report as a bug until proven otherwise, because players rarely report a game that works fine.
The lesson for anyone with a large catalogue
Test the structure, not the content. Confirm that things load, render, and respond, and let humans handle the judgement calls. A catalogue of 56,000 games does not need 56,000 playthroughs. It needs a small number of reliable checks, run constantly, plus a fast path from player report to fix.
If you run a large content site, free or otherwise, the same principle applies. Automate the crude failures, which are the most common and the most embarrassing, and spend your human attention on quality, which is where it actually matters.
You can see the result at GameZiko, where every game is one click away, no downloads, no sign-ups, and, we hope, working when you open it.
Top comments (0)