Tommy Lahitte
QA Workflow

Build a Real Pre-Release Test Pass

A stable editor session is not a release signal. This Unreal-focused pre-release pass combines packaged builds, smoke automation, performance captures, and log review so regressions show up before players do.

testingautomationciprofilingpackaging

Right before release is where teams over-trust PIE and under-test the packaged game. My rule is simple: if the feature hasn't survived a packaged smoke pass, a short performance check, and a log review, it's not done. You don't need a huge QA department for this, but you do need a repeatable checklist.

Overview

  • Package a Development build for the target platform
  • Run an automated smoke suite before manual testing
  • Perform a focused manual pass on startup, save/load, input, and platform-specific risks
  • Capture performance baselines and scan logs/crashes before sign-off

Step 1: Start from a packaged Development build

I avoid making release decisions from editor behavior alone. Package a Development build first so logs and symbols stay useful while runtime behavior stays close to the final game. If that build isn't stable, a Shipping package won't magically fix the problem.

bash
RunUAT.bat BuildCookRun ^
  -project="D:\Projects\MyGame\MyGame.uproject" ^
  -platform=Win64 ^
  -clientconfig=Development ^
  -build -cook -stage -package -pak -archive ^
  -archivedirectory="D:\ReleaseCandidates\RC_014"

REM A release candidate should be a reproducible archive, not a local editor state.

Step 2: Run a smoke suite first

Before anyone starts manual testing, run a small automation suite that proves the build launches, loads required maps, and enters the core game loop. Smoke tests catch obvious breakage fast and stop the team from wasting manual hours on a dead build. Keep them short, deterministic, and high value.

bash
UnrealEditor-Cmd.exe "D:\Projects\MyGame\MyGame.uproject" ^
  -ExecCmds="Automation RunTests Project.Smoke; Quit" ^
  -unattended -nop4 -nosplash -NullRHI -log

REM -NullRHI removes GPU cost so CI can run simple tests on headless agents.
REM Keep smoke tests focused on launch and core flow, not deep gameplay coverage.

Step 3: Manual pass the things automation misses

Automation is great at repetition, but manual QA still matters for feel, UX, and edge conditions. I keep the release pass short and targeted rather than trying to replay the whole project. The checklist should focus on the failures that are expensive after release.

  • Cold startup, first-run settings, and title screen navigation
  • Save creation, load, overwrite, and corrupted or missing save handling
  • Input device changes, remapping, focus loss, alt-tab, and pause/resume
  • Map transitions, streaming-heavy areas, respawn, and checkpoint recovery
  • Known high-risk features from the current sprint

Step 4: Capture a quick performance baseline

A release candidate should ship with known performance numbers, not vibes. I usually capture a short Unreal Insights trace and grab a few stat commands in the heaviest level or gameplay sequence. That gives me a reference for frame time, streaming pressure, and obvious render or game-thread regressions.

bash
MyGame-Win64-Development.exe -trace=cpu,frame,bookmark,loadtime,file,memory -statnamedevents -log

REM Start the packaged build with trace channels enabled so the session is ready for Insights.
REM Add bookmarks during the run around menu load, combat start, and map travel.
bash
stat unit
stat game
stat gpu
stat memory
stat streaming
stat levels

# These are my default live checks during a release candidate pass.
# They quickly tell you if the regression is thread time, memory pressure, or streaming related.

Step 5: Review logs before sign-off

I always skim the packaged log after the pass, even when nothing visibly broke. Warnings about failed loads, bad soft references, missing inputs, or subsystem startup problems often show up before the player-facing bug does. Quiet logs are one of the best predictors of a clean release.

Don't normalize recurring warnings just because the build 'works.' A warning that repeats every frame or on every level transition is already a QA issue, even if players haven't noticed it yet.

This workflow is intentionally lightweight. One package, one smoke run, one focused manual pass, one short performance capture, one log review. If you do that consistently, your release process gets a lot less dramatic.

Source Reference

Inspired by a discussion on r/unrealengine (4 upvotes, 12 comments)

Related Tips

Don't Commit Binaries to Source Control

For Unreal C++ projects, committing Binaries usually creates stale build problems, larger repos, and harder CI cleanup. Track source, config, content, and project files instead, then regenerate outputs locally or in CI.

Automating QA Checks with Functional Tests

Unreal's Functional Testing framework lets you write repeatable, CI-friendly test maps that verify gameplay logic, performance budgets, and visual correctness automatically.

Capture Unreal Insights Traces with the Right Arguments

Unreal Insights trace files give you a frame-by-frame breakdown of CPU, GPU, task graph, rendering commands, and more. The right combination of -trace= channels makes the difference between a useful trace and an overwhelming one.