Quick answer: Test both docked and handheld modes, sleep and resume from any state, tight memory budgets, and every Joy-Con and controller configuration. The Switch has strict certification and unique constraints, so a focused checklist plus crash capture on real hardware is what gets you through.
Launching on the Nintendo Switch is a different discipline from launching on PC. The platform has strict certification requirements you must pass, a much tighter performance and memory budget than a modern PC, and unique behaviors, docked versus handheld modes, sleep and resume, detachable Joy-Cons, that simply do not exist elsewhere. An indie game that runs beautifully on PC can fail certification or crash on a Switch for reasons that never came up in development. This checklist covers the Switch-specific QA that gets you to launch.
Certification is mandatory and strict
Unlike open platforms, the Switch requires you to pass platform certification before you can launch, and the requirements are detailed and strictly enforced. They cover behaviors like correct handling of the home button, suspend and resume, controller disconnection, error messages, and storage. Failing certification means delays and resubmission, so you treat the requirements as a hard checklist, not a guideline.
Build your QA process around the certification requirements from the start rather than discovering them at submission. Many of the requirements concern system behaviors, how your game responds to being suspended, to a controller disconnecting, to storage being full, that are easy to overlook because they are not part of your core gameplay but are exactly what certification scrutinizes. Knowing them early shapes how you build, not just how you test.
Test docked and handheld modes
The Switch runs in two modes with different performance profiles and different screen resolutions: docked, where it outputs to a TV at higher resolution and power, and handheld, where it runs on the built-in screen at lower resolution and reduced clocks. Your game must handle both, and crucially must handle switching between them mid-session without crashing or rendering incorrectly.
Test the transition specifically, undocking and docking during gameplay, in menus, during loading, because the mode switch is a frequent source of crashes and rendering bugs. Performance must be acceptable in both modes, and the lower handheld clocks mean a game that hits the frame rate target docked may miss it in handheld, so test performance separately in each mode rather than assuming docked performance carries over.
Sleep, resume, and suspension
Players put the Switch to sleep constantly, mid-game, mid-cutscene, mid-loading, by pressing the power button or closing the lid, and your game must survive being suspended and resumed from any state. Certification tests this, and players will do it relentlessly, so a game that crashes or corrupts state on resume will both fail certification and frustrate players.
Test suspending and resuming from every state you can: during gameplay, during saves, during network operations, during loading screens. Pay special attention to anything time-based or network-based, because the gap introduced by sleep can break assumptions about elapsed time or connection state. Resume handling is one of the most Switch-specific behaviors and one of the most common reasons indie ports stumble.
Memory and performance constraints
The Switch has far less memory and processing power than a modern PC or current consoles, and a game that never worried about memory on PC can blow the Switch budget easily. Test against the real memory ceiling on actual hardware, because exceeding it causes crashes that never appear on your development PC. Large textures, uncompressed audio, and unbounded allocations are common culprits.
Performance requires real-hardware testing too. The Switch CPU and GPU are modest, and effects, draw distances, and physics loads that are free on PC can tank the frame rate on Switch. Profile on the device, in both docked and handheld modes, and be prepared to scale down settings specifically for the platform. Capturing crashes and performance data from real hardware during testing is essential, because the constraints are invisible on your PC.
Joy-Con and controller handling
The Switch controller situation is uniquely complex: detachable Joy-Cons that can be used together, separately, in a grip, or as a Pro Controller, plus the handheld built-in controls. Your game must handle all the supported configurations and the transitions between them, a Joy-Con detaching mid-game, switching from handheld to a Pro Controller, a controller disconnecting.
Certification checks controller handling, including showing the correct prompt to reconnect a controller, and players use every configuration, so test them all. The detach and reconnect flows are the most error-prone, since they involve the system controller-management UI and your game pausing appropriately. A game that handles a Pro Controller but mishandles a single detached Joy-Con will frustrate a meaningful slice of Switch players and may fail certification.
A Switch launch QA checklist
Use this as the backbone of your Switch QA, expanding it with the specific certification requirements for your title. Test everything on real hardware, because the Switch constraints simply do not reproduce on a PC, and capture crashes and performance data throughout so you fix the platform-specific issues before submission rather than discovering them in a certification failure.
Nintendo Switch launch QA checklist:
[ ] Review and test against all applicable certification requirements
[ ] Test docked mode performance and rendering
[ ] Test handheld mode performance and rendering
[ ] Test docking and undocking mid-gameplay, in menus, and while loading
[ ] Test sleep and resume from gameplay, saves, loading, and network operations
[ ] Verify memory stays within budget on real hardware
[ ] Profile frame rate on device in both modes
[ ] Test all supported Joy-Con and Pro Controller configurations
[ ] Test Joy-Con detach, reconnect, and disconnect handling
[ ] Verify correct home button and error handling
[ ] Test behavior when storage is full
[ ] Capture crashes and performance data on real hardware