What are the best practices for verifying bug fixes?

Confirm the bug actually stopped on the build that shipped the fix, using per-version tracking, since a fix that looks right can still fail to address the real cause, and watching the bug disappear on the fixed version is real verification while assuming it worked because the code looked correct is not. Verify in the field rather than assuming, watch real player data on the fixed version, especially for bugs you couldn't reproduce, since local testing can't cover every condition and field verification confirms the fix worked under the real conditions that triggered the bug. And check the fix didn't introduce a regression, test the surrounding areas the change touched and monitor the fixed build's overall health per version, since a fix changes code which can break something else. A fix isn't done when you write it, it's done when you've verified it worked and didn't break anything else, so verifying means confirming both that the bug is gone (on the fixed build, in the field) and that the fix was a net improvement (no new regression). Per-version tracking is what makes this verification possible, by letting you watch the bug stop and the build's health on the specific version that shipped the fix.

How do I know if a bug fix actually worked?

Confirm the bug stops occurring on the build that shipped the fix, in the field, using per-version tracking, rather than assuming it worked because it looked right or stopped reproducing locally. Tag the fix to the build it shipped in, then watch that version's data: if the bug that was occurring on previous builds no longer appears on the fixed build as players adopt it, the fix is verified in the real world. This matters because fixes that seem correct can fail to address the actual field condition, or fix only one of several causes grouped under the same bug, so the bug looked fixed in your testing but persists in the field. Verifying in the field is especially important for bugs you couldn't reproduce, since you can't confirm those by local re-testing (you couldn't make them happen in the first place), so watching whether they stop in the field is the only reliable verification. The key is to verify by evidence (the bug stopped on the fixed version, in real player data) rather than by assumption (the code change looks correct), because the gap between a fix that looks right and one that actually works is exactly where assumed-fixed bugs come back. Per-version tracking gives you this evidence by letting you watch the specific build that shipped the fix and confirm the bug is gone on it, which is how you know a fix truly worked.

Why verify a bug fix in the field instead of just testing it?

Because local testing can't cover every condition, so a fix that passes your testing can still fail under the real-world conditions that triggered the bug, and field verification is the only way to confirm it works where it matters. Your testing covers a limited set of devices, configurations, and scenarios, while the bug may have occurred under conditions you can't fully recreate, a specific device, OS version, or state, so confirming the fix works in your test environment doesn't guarantee it works in the field. This is especially true for bugs you couldn't reproduce: if you couldn't make the bug happen locally, you can't confirm the fix locally either, the only way to know is to ship the fix and watch whether the bug stops occurring in the field on the fixed version. Field verification, watching real player data per version, confirms the fix worked under the actual conditions that triggered the bug, including conditions your testing couldn't reproduce, which is exactly where a fix that passed testing might still fail. It also catches fixes that addressed only part of the problem (one of several causes under the same signature) by showing the bug continuing at reduced but nonzero rates. So while testing the fix before shipping is valuable (you don't want to ship an unverified fix), field verification after shipping is what actually confirms the fix worked in the real world, by providing evidence from the real conditions rather than the assumption that your test environment matched them. Per-version tracking makes this field verification direct, letting you watch the bug stop on the build that fixed it.

Best Practices for Verifying Bug Fixes

Quick answer: Confirm the bug actually stopped on the build that fixed it, verify in the field rather than assuming, and check the fix didn't introduce a regression. A fix is done when verified, not when written.

Writing a fix isn't the same as fixing the bug, you have to verify the fix actually worked. Here are the best practices for verifying bug fixes.

Confirm the Bug Actually Stopped on the Fixed Build

A fix that looks right can still fail to address the real cause, so confirm the bug actually stopped on the build that shipped the fix, using per-version tracking. Watching the bug disappear on the fixed version is real verification; assuming it worked because the code looked correct is not.

Bugnet tracks crashes per version, so you can confirm a bug stopped on the build that fixed it. Confirming the bug stopped on the fixed build is real verification, since a fix that seems correct can miss the actual field condition or fix only one of several causes.

Verify in the Field Rather Than Assuming

Local testing can't cover every condition, so verify in the field, watch real player data on the fixed version, especially for bugs you couldn't reproduce. Field verification confirms the fix worked under the real conditions that triggered the bug, which local re-testing might not reproduce.

Bugnet captures crashes from the field per version, so field verification is direct. Verifying in the field rather than assuming catches the fixes that work locally but not in the real conditions, which is exactly where assumed-fixed bugs come back.

Check the Fix Didn't Introduce a Regression

A fix changes code, which can break something else, so check the fix didn't introduce a regression, test the surrounding areas and monitor the fixed build's overall health per version. Verifying a fix means confirming both that the bug is gone and that nothing else broke, so the fix is a net improvement.

Bugnet tracks crash rate per version, so a fix-induced regression surfaces on the fixed build. So practice verifying bug fixes by confirming the bug stopped on the fixed build, verifying in the field, and checking for regressions, making a fix done when verified, not when written.

Confirm the bug actually stopped on the build that fixed it, verify in the field rather than assuming, and check the fix didn't introduce a regression. A fix is done when verified, not when written.