What is the difference between smoke testing and regression testing?

Smoke testing is a fast, shallow check of fundamental functionality to confirm a build is worth testing at all. Regression testing is more thorough re-verification that existing features still work after a change. Smoke testing gates whether to proceed; regression testing checks that a change did not break previously-working behavior.

Why do a smoke test before deeper testing?

To fail fast and cheaply. Deeper testing is expensive, and running it on a fundamentally broken build, one that does not even launch, is wasted effort. A quick smoke test catches broken builds at the gate so only builds that pass the basics get the deeper testing, and it provides a fast confidence signal on every build in an active development cycle.

What Is Smoke Testing for Game Builds?

Q: What is smoke testing?

A quick, shallow check that a build's most basic functionality works, does it launch, load, and run the core flow, before investing in deeper testing. The name comes from hardware testing (power it on and see if smoke comes out). It is a gate: if a build fails the smoke test, you reject it immediately rather than testing further.

Quick answer: Smoke testing is a fast, surface-level verification that a build is fundamentally functional: it launches, loads, and the core paths work. The name comes from hardware testing (power it on and see if smoke comes out). It is a gatekeeping check, if a build fails the smoke test, you do not bother with deeper testing; you reject it and fix the basics first.

Before you spend hours testing a build in depth, you want to know it is even worth testing, that it launches and basically works. Smoke testing is that quick sanity check. The term comes from electronics, where you power on a new circuit and see if smoke literally comes out. In games, a smoke test is a fast pass over the most fundamental functionality, a gate that catches broken builds early so you do not waste deeper testing effort on something that does not even start.

What a Smoke Test Covers

A smoke test checks breadth shallowly, not depth. It verifies the most basic, critical functionality: does the build launch without crashing, does the main menu load, can you start a game, does the core loop run, can you save and load? It touches the essential paths just enough to confirm they are not completely broken. It deliberately does not dig deep, the point is speed and breadth of the fundamentals, not thoroughness.

Think of it as confirming the build is alive and functional at a basic level. A smoke test should be quick, minutes, not hours, and cover the things that, if broken, would make any further testing pointless. If you cannot launch the game, there is no reason to test the inventory system; the smoke test catches that the launch is broken first.

Why Smoke Test

The purpose of a smoke test is to fail fast and cheaply. Deeper testing is expensive (in time and effort), and running it on a fundamentally broken build is wasted effort. By quickly verifying the basics first, you catch broken builds at the gate, before anyone invests in detailed testing. A build that fails the smoke test is rejected immediately and sent back to be fixed; only builds that pass are worth the deeper testing.

Smoke testing also gives a fast confidence signal for every build. In an active development cycle producing frequent builds, a quick smoke test on each one continuously confirms that the fundamentals are intact, so a basic regression (the build stopped launching, saving broke) is caught immediately rather than discovered deep into a testing session. It is a cheap, frequent health check on your build pipeline.

Smoke Testing in Practice

A smoke test is often a short, defined checklist of the critical basic functions, run on each new build, manually or automated. Keep it focused: only the truly fundamental things whose breakage would block further testing or shipping. The discipline is to actually run it on every build and to treat a failure as a hard stop, do not proceed to deeper work or release on a build that fails its smoke test.

When smoke tests do catch a broken build, the failures still want capturing so they can be diagnosed and fixed. Automatic crash capture during smoke testing means a build that crashes on launch arrives with a stack trace and context, so you know not just that it failed but why. Bugnet's crash reporting captures these failures with context and ties them to the build version, so a build that fails its smoke test gives you the diagnostic information to fix the fundamental break quickly, get a passing build, and move on to the deeper testing the smoke test was gating.

A smoke test asks 'does this build even work?' before you invest in deep testing. Fail fast, fail cheap, reject broken builds at the gate.