Six Bugs That Pass Every Playtest - and Still Fail Console Certification
Some bugs never show up in a normal playtest, but they stop a release at certification. Six classic examples - from a controller unplugged mid-save to a German tooltip that hides a button - and how to catch them long before submission.
Przemysław ChmuraBusiness Development Representative
Some bugs pass every playtest. And then they stop a release.
When I talk to studios about porting, certification is usually the part they are most nervous about - and the part they know least about. That makes sense. Most of the problems that fail console certification are not crashes in the middle of a boss fight. They are quiet, boring situations that nobody plays on purpose: an unplugged controller, a full hard drive, a console that sleeps for the whole weekend.
In this article I want to walk through six classic examples, explain why each one slips past a normal playtest, and show what catches them before a build ever goes to a platform holder.
Why normal playtests miss certification bugs
A playtest answers one question: is the game fun and does it work when you play it? A good tester follows the game - levels, quests, menus, combat.
Certification asks a different question: does the game behave correctly no matter what the player or the console does around it? Every platform holder has its own technical requirements checklist covering things like controllers, saves, user accounts, system features and wording. Those requirements are confidential, so I won't quote any of them here. But the categories are well known across the industry - and so are the bugs that hide in them.
A quick note before the list: these are not stories from one specific project. They are the classic cases that come up again and again in console QA, described without game names or platform requirement numbers.
1. The controller that left mid-save
What happens: A player pulls the controller out - or the battery dies - exactly while the game is autosaving. The save finishes fine. But the game shows its "reconnect your controller" screen and then waits forever, even though the controller is already back in the player's hands.
Why playtests miss it: Nobody unplugs a controller on purpose, and certainly not during a two-second save.
What the platforms expect: A controller disconnect has to be handled anywhere and at any time - in gameplay, in menus, on loading screens and during saves - and the game must recover cleanly when the controller comes back.
How to catch it: Treat disconnects as a test case of their own, and run it in every state of the game, not just in gameplay.
2. "Press A" on a PlayStation
What happens: Ninety-nine screens show the correct DualSense prompts. One menu, deep in the options, still shows the button prompt from the PC or Xbox version.
Why playtests miss it: Testers play through the main flow. Nobody opens the "advanced audio settings" screen with a PlayStation controller - until a certification tester does.
What the platforms expect: Every controller glyph, button name and controller term has to match the platform the game is running on. "Press A" on a PlayStation is a failure, and so is using another platform's name for a controller or a feature.
How to catch it: Search the project for hard-coded prompts and button names instead of trusting screen-by-screen checks. We wrote more about console interfaces in UX and UI on consoles.
3. The weekend in rest mode
What happens: The player puts the console into rest mode on Friday evening, mid-game. On Monday they pick the controller up again. The online session expired days ago, and the game sits on a loading spinner that never finishes.
Why playtests miss it: Test sessions last hours, not days. Resuming after five minutes usually works fine.
What the platforms expect: System suspend and resume must bring the player back to a working game, whether the console slept for a minute or for three days - including when the network connection, the user's sign-in or the online services changed in the meantime.
How to catch it: Test resume after long suspensions, with the network removed and restored while the console sleeps.
4. The German tooltip
What happens: The interface was designed in English. In German, one tooltip grows past its box and covers the button the player needs to continue.
Why playtests miss it: Most of the team plays in one language. The longest translations arrive late, often after the UI is considered "done".
What the platforms expect: The game has to be fully usable in every language it ships with. Text that overlaps, gets cut off or hides an element is a classic finding.
How to catch it: Plan for text expansion from the start, and include localization QA that checks every screen in every language - not just the strings in a spreadsheet.
5. The full hard drive
What happens: The player's storage is almost full. The game starts writing a save, runs out of space halfway through and leaves a corrupted file behind. An evening of progress is gone.
Why playtests miss it: Dev kits and test consoles rarely run out of space.
What the platforms expect: Save data compliance covers what happens when there's no space, when a save is corrupted and when power is lost during a write. The game has to tell the player what's going on - and never destroy the previous good save.
How to catch it: Fill the storage on purpose and save in every possible place. Write saves so that a failed write can't overwrite the last working one, and respect each platform's storage quota.
6. The second player who signed in
What happens: Two people share a console. Mid-session, the user changes. The game keeps going - and achievements, trophies and save progress land on the wrong profile.
Why playtests miss it: Test consoles usually have one test account signed in all day.
What the platforms expect: User account handling is part of the game flow: the right user from the first screen, clean handling of sign-out and user changes, and saves that never get mixed between people.
How to catch it: Test with several accounts on one console, and switch users in the middle of gameplay, saves and online sessions.
The pattern: certification tests the unhappy paths
Put the six side by side and the pattern is obvious:
| Bug | The unhappy path | Area |
|---|---|---|
| The controller that left mid-save | Controller disconnects during a save | Input |
| "Press A" on a PlayStation | A rarely visited menu | Platform wording |
| The weekend in rest mode | Resume after days, network changed | System features |
| The German tooltip | Longest translation | Localization |
| The full hard drive | No storage space while saving | Save data |
| The second player who signed in | User switch mid-session | Accounts |
None of them is about the game being broken in the way players imagine. They are about the game behaving correctly around everything else the console and the player can do. That's exactly why they survive normal testing - and why each one can send a build back for another round.
And a failed round costs more than a bug fix. It means fixes, retesting and another wait before the platform holder looks at the build again. On a tight release plan, one certification failure can move a launch date.
How we catch them before submission
The short version: we don't wait for certification to tell us about them.
- Unhappy paths are tested from day one. Unplugged controllers, full storage, long rest mode, user switching and every language are part of our regular test plans, not a pre-submission panic.
- Certification readiness is built into development. Platform requirements are checked continuously throughout the project, not at submission time.
- QA is in-house. Our team covers functionality, localization and compliance testing (FQA, LQA and CQA), and we coordinate certification with platform holders directly.
- Fixes don't quietly break other platforms. Regression testing makes sure a fix for one console doesn't undo work on another.
It pays off. The Cub, which we ported to Xbox Series X|S and Xbox One, passed certification on the first attempt - as its publisher put it:
"Lynci made porting far more cost-effective and easier to manage, letting us bring the release to more platforms. The game also passed certification on the first attempt - proof of how reliable the tool is."
Ewa Buczkowska, Producer, Untold Tales
If you want to see what else tends to go wrong in a port, my colleague Sylwester wrote about the biggest mistakes we see in game ports. And if you're wondering what happens if something still goes wrong after launch, here's how our delivery guarantee works in practice.
What's the strangest bug you've seen?
Every studio that has shipped on console has at least one story like these. I'd love to hear yours.
And if you're planning a port and want to know how ready your game is for certification, get a free estimate. Within 3 business days you'll get a first estimate of the scope, free and with no commitment.
Frequently Asked Questions
Why do games fail console certification?
Most failures come from situations that normal playtests don't cover: controller disconnects, suspend and resume, user switching, full storage, wrong button prompts or platform wording, and text problems in translations. Certification checks how the game behaves around everything the player and the console can do, not only how it plays.
Can a game pass playtesting and still fail certification?
Yes. Playtests follow the game itself, while certification focuses on platform requirements and "unhappy paths" - situations players rarely create on purpose, like unplugging a controller during a save or leaving the console in rest mode for days.
What are the most common console certification issues?
Common categories include controller handling, button prompts and platform terminology, suspend and resume, save data handling, user accounts, network loss, achievements and trophies, and localization issues such as text that overflows its box.
How do you prepare a game for console certification?
Test the unhappy paths from the start of the project, check platform requirements continuously rather than just before submission, run localization QA on every screen in every language, and use regression testing so fixes on one platform don't break another.
What happens if a game fails certification?
The platform holder sends the build back with a list of issues. The team fixes them, tests again and resubmits - which adds time and can move a release date. That's why catching these bugs before submission matters so much.
Does LYNXBYTE GAMES handle console certification?
Yes. Our in-house QA team covers functionality, localization and compliance testing, and we coordinate certification with platform holders directly as part of the porting project.
