Thirty hours of pre-launch game testing finds the bugs players hit first: crashes on first launch, broken settings, progression blockers on the critical path, lost saves, controller dead ends and frame drops on minimum spec. That is the scope of a 30-hour pass split across up to two testers. Large multiplayer loads, platform certification and full localization review sit outside it.
How are 30 hours split before a Steam launch?
The split below is an editorial estimate of how a 30-hour pass is usually planned. Each block follows the order in which players meet the game. The first block exists because Steam refunds any game bought within 14 days and played for less than two hours (Steam Refunds, accessed 27 Oct 2026). Whatever breaks in the first two hours is what gets refunded and reviewed.
For a concrete picture of the output, our sample QA report shows a full report for “Example Game”, a fictional title made up to show the format: summary, top risks, severity counts and five complete bug entries with repro steps.
| Block | Hours (editorial estimate) | What testers do | Typical finding |
|---|---|---|---|
| 1. First launch and settings | 4 | Clean install, first boot, every settings menu, resolution and language changes, first two hours of play | Crash on a resolution change, a setting that resets on restart |
| 2. Critical path | 10 | Play the main route start to finish, then take wrong turns, backtrack and reload mid-scene | Progression blocker, a door or lever that stops responding |
| 3. Saves and quitting | 4 | Save, load, autosave, quit at bad moments, relaunch, continue | Corrupted or overwritten save slot |
| 4. Controller and input | 3 | Full run on a gamepad, menu navigation, rebinding, button prompts | Menu tab reachable only with a mouse |
| 5. Hardware tiers | 5 | Same scenes on low, mid and high PCs, with an FPS overlay | Frame drop below the minimum spec promise |
| 6. Regression and fix checks | 4 | Re-test fixed bugs on the next build, re-run the riskiest paths | A fix that breaks a neighbouring system |
| Total testing | 30 | ||
| Team Lead | 5 | Test plan, triage, merging duplicates, report review, debrief | One prioritized report instead of two sets of notes |
Ten hours go to the critical path because it is the only block every player goes through end to end. Saves get their own four hours since save bugs combine high severity with timing-dependent repro. In the sample report, the worst one appeared only when a player quit during an autosave.
If the build is a short Next Fest demo, the critical path block shrinks and the hardware and controller blocks grow. A Launch Health Check runs on this plan: up to two testers, around 30 hours of testing plus 5 hours of a Team Lead, and the first prioritized report within 3 business days of receiving the build.
What does the report look like when 30 hours are done?
The sample report lists 25 bugs for its fictional build: 2 critical, 5 major, 11 minor and 7 cosmetic. Treat that mix as an editorial estimate based on our sample report. It illustrates format and proportion, and client projects vary. A clean build can produce half as many entries, and a rushed one can produce twice as many.
Every bug gets two separate ratings. Severity says how bad it is for the player. Priority says how soon to fix it given the milestone.
| Severity | Definition (from the sample report) | Example from “Example Game” | Suggested priority |
|---|---|---|---|
| Critical | Crash, freeze, progression blocker, save or data loss | Save corrupted when quitting during autosave, 4/5 repro | P1: fix before release |
| Major | A feature is broken or a serious issue affects many players, with a workaround | FPS drops to about 18 in one area on minimum spec | P2: fix soon (first patch at the latest) |
| Minor | Works, but not as intended; players notice and carry on | Wrong item count after crafting | P3: fix when possible |
| Cosmetic | Visual, audio or text polish | French tooltip overflowing its box | P3 or P4: backlog, studio decides |
The two scales split on purpose. A cosmetic typo in the main menu can deserve P2 because every player sees it. A major bug in an optional late area can wait for the first patch.
Each entry in the sample also carries the build ID, hardware, a reproducibility rate such as 5/5 or 3/5, numbered steps, expected and actual results, and a video timestamp. That format lets a programmer start fixing without a follow-up question.
What did testing actually catch on shipped Steam games?
The four examples below come from our public case studies. They came out of longer engagements than a 30-hour pass. Each one shows the class of bug a specific block exists to catch, on a game that is live on Steam today.
Blood West: a patch-day AI break traced to the NavMesh
On patch release day, enemy AI in Blood West started behaving erratically, and the cause was not obvious. Our most experienced tester traced it to the AI’s NavMesh, which had been corrupted during recent updates. The developers shipped a focused fix and avoided rolling the patch back. Blood West sits at 90% positive. Block 6 targets exactly this class of bug, where something that worked last build quietly breaks in this one.
Frozenheim: multiplayer stress tests with rising unit counts
Players of Frozenheim reported lag, disconnects and crashes in multiplayer. Early guesses pointed at the number of active units, but the exact cause was unclear. Testers worked with the developers on stress tests that raised unit counts and in-game interactions step by step, with detailed logs. The developers then optimized network handling and resource management. The game has sold over 300,000 copies.
POSTAL: Brain Damaged, every speedrun route re-run after a major update
Before a significant update to POSTAL: Brain Damaged, the developers wanted to know whether known speedrun routes would survive. Our in-house speedrunner played the whole game post-update and tested every known route and strategy. The update shipped with the community’s routes intact. The game holds 95% positive reviews. It is a sharper version of the critical path block, played the way the most dedicated players play.
Hordes of Hunger: a map-wide collision sweep and camera notes
In the alpha of Hordes of Hunger, players met invisible walls, fell through solid objects and moved unnaturally in several areas. Testers explored the entire world and documented every collision issue with location references, repro steps and video. The team resolved all reported collision issues. The same project produced camera feedback across combat, exploration and area transitions, and the developers refined the camera to feel more responsive.
Which findings tend to come up in a first pass?
The sample report shows the pattern in miniature. Its top three risks were a save corrupted on quit, a lever that stopped responding after a reload, and a frame drop on minimum spec. Each one maps to a block from the table above: saves, critical path and hardware tiers.
A few habits explain why outside testers find these and in-house teams often do not:
- They start from a clean install and a new profile, so first-run bugs are still visible.
- They quit, reload and alt-tab at the worst possible moment on purpose.
- They play on a minimum spec machine instead of a development workstation.
- They play the whole game on a gamepad, including every shop and menu.
- They record reproducibility as a ratio, so a 1/10 crash is not dismissed as a fluke.
Game-feel notes come along too. The fictional sample flagged a boss that took both testers 8 to 10 attempts, against 1 to 3 for earlier fights. The report files it as a note for the studio to judge, worth a look before Early Access reviews arrive.
In the Steam Launch Bug Index, October 2026 edition, the median September 2026 launch had 6.5% of its first-14-day reviews mention a bug, crash, stutter or freeze, and a quarter of launches were above 12.7% (n=592, computed 27 October 2026).
What does 30 hours of testing not cover?
A 30-hour pass is a health check of what players hit first. Three areas need their own plan.
Multiplayer at scale. Two testers can confirm that hosting, joining and a basic match work. They cannot simulate a full server or a crowded late-game map. Frozenheim needed dedicated stress tests designed together with the developers, plus log analysis, to find the cause of its disconnects. Multiplayer testing is a separate add-on.
Platform certification. Console certification follows each platform holder’s own requirements and is a different discipline. Jumbo Jelly tests PC games on Steam and does not take certification work.
Full localization review. A 30-hour pass can catch broken layouts in a second language, like the French tooltip overflow in the sample report. Reviewing the meaning and tone of every line is a different job. On Frozenheim, a native French speaker reviewed the game’s entire French content, across narrative, UI and dialogue. On POSTAL: Brain Damaged, the work covered dialogue, UI text and in-game references so the humor survived in French.
Content that is not in the build is out of scope too. The sample report lists Chapter 4 as not covered because it was not in the build. Any honest report lists what it did not test, so the studio knows where the remaining risk sits.
How should a studio use the 30-hour report?
Treat the first report as a fix list and a map of remaining risk:
- Fix every P1 before the build goes public.
- Send the next build back for a regression pass on the systems those fixes touched, starting with saves.
- Re-check performance bugs on all three hardware tiers after any optimization.
- Move P2 items into the first patch plan and keep P3 and P4 in the backlog.
- Read the coverage section and decide whether multiplayer, localization or late content needs its own round.
The 30-minute debrief is where that last decision gets made. Some studios stop after one pass and keep the report. Others turn the findings into a recurring test round before each patch.