QA Testing for Ad Integration and Rewarded Ads

Rewarded ads are a deal with the player: watch this video and get a reward. Honoring that deal is harder than it looks, because the ad itself comes from a third-party network you do not control, over a network connection that fails, through an SDK that has its own bugs and edge cases. The player does not care that the ad network had no inventory or that a callback was dropped, they watched the ad and they expect their reward. A rewarded ad system that sometimes fails to pay out, or that strands the player on a frozen ad, breaks trust and costs you the engagement the ad was meant to drive. This post is about testing ad integration so the deal always holds.

Test the full ad lifecycle

A rewarded ad has a lifecycle: request an ad, the network fills it or does not, the ad loads, the player chooses to watch, the ad plays, the ad completes, and the reward callback fires. Each stage can fail independently, so test them as distinct steps. Confirm that requesting an ad eventually produces either a loaded ad or a clean no-fill, that a loaded ad shows on demand, that watching it to completion fires the reward, and that the reward is actually granted in your game economy. Treating the ad as a single opaque operation hides the many places it can break midway.

Pay attention to the asynchronous, callback-driven nature of ad SDKs, because that is where bugs breed. The ad loads on one callback, shows on another, completes on a third, and rewards on a fourth, and these can arrive out of order, late, or not at all. Test that your code handles each callback defensively and does not assume they always fire in the happy sequence. An ad integration that works when the network is fast and cooperative but mishandles a delayed or missing callback will fail intermittently in production in ways that are maddening to reproduce without deliberate testing of each stage.

No-fill is the normal case, not an error

Ad networks frequently have no ad to serve, especially in smaller markets, for certain audiences, or at certain times. This no-fill is not an error, it is a routine outcome you must handle gracefully. Test what the player sees when no ad is available: the rewarded button should communicate that no ad is ready right now, not spin forever or show a broken state. Confirm the player is not stranded waiting, that the game stays fully playable, and that they can try again later. A no-fill that looks like a crash makes players think your game is broken when the ad network simply had nothing to show.

Test no-fill across the conditions where it actually happens, which you can often force with the ad network's test configuration. Confirm your retry and caching logic behaves: do you pre-load ads so one is usually ready, do you back off sensibly when fills are scarce, do you avoid hammering the network. The goal is that the rewarded offer gracefully reflects ad availability, present when an ad is ready and clearly unavailable when it is not, without ever leaving the player confused, stuck, or staring at a button that does nothing when they tap it expecting a reward.

The reward must always be delivered

The cardinal rule of rewarded ads is that a player who completed an ad gets their reward, full stop. The most damaging bug is a player watching a thirty second video and receiving nothing, because the reward callback was dropped, arrived late, or the app was backgrounded during the ad. Test the reward delivery against every interruption: background the app mid-ad and return, lose network during the ad, kill and relaunch right after the ad completes. In each case, confirm the player ends up with their reward, because anything else trains players that watching ads is a waste of their time.

Build the reward grant to be resilient rather than trusting a single callback. Test that a reward earned but not yet granted because of an interruption is reconciled on next launch, so a dropped callback becomes a slightly delayed reward rather than a lost one. Test that the reward is granted exactly once, not zero times and not twice, even if callbacks duplicate. The reward economy is the entire point of the rewarded ad, so the path from ad-completed to reward-granted must be the most robust, most thoroughly tested part of your entire ad integration, surviving every interruption the real world throws at it.

Test the player closing the ad early

Rewarded ads let the player close early without earning the reward, and this branch is a common source of bugs. Test closing the ad before the reward threshold and confirm the player gets no reward and is returned cleanly to the game with no broken state. Test closing exactly at the completion boundary. Test the difference between the player skipping a skippable portion and abandoning the whole ad. The distinction between a completed ad that earns the reward and an abandoned one that does not must be crisp, because both over-rewarding and under-rewarding here create problems.

Closing the ad also exercises the return-to-game path, which has its own failure modes. Test that dismissing the ad restores game audio, resumes gameplay, removes the ad view cleanly, and does not leave the game paused, muted, or showing a lingering overlay. Ad SDKs take over the screen and audio during playback, and handing control back to your game is a transition that frequently glitches. A player who closes an ad and finds their game muted, frozen, or stuck behind an invisible ad layer will blame your game, not the ad network, so test the dismissal path as carefully as the completion path.

Setting it up with Bugnet

Ad failures are intermittent and tied to a third-party SDK you do not control, so reproducing them without field data is painful. With Bugnet, when the ad SDK crashes or your reward-granting code throws, the crash is captured with a stack trace and device context, landing in your dashboard automatically. When a player completes an ad but the reward does not arrive, you can fire an in-game report capturing the game state, the ad placement, the network status, and the platform, so instead of a vague complaint that ads do not pay out, you get a concrete report of exactly where in the ad lifecycle the reward was lost.

Custom fields are perfect for ad context: tag reports with the ad placement, the lifecycle stage, the ad network, and the platform, and Bugnet's occurrence grouping shows whether a reward failure is widespread or isolated. If a cluster of reports all show the reward callback failing on one ad network after an SDK update, you have a monetization regression with a clear fingerprint. One dashboard, filtered by ad-related custom fields, turns the scattered, hard-to-reproduce complaints about missing rewards and frozen ads into a prioritized list of exactly which placements and networks are misbehaving.

Honor the deal every time

The throughline of rewarded ad testing is that you are honoring a deal with the player, and the third-party machinery between you and that deal is unreliable. Your testing has to assume the ad network will no-fill, the callback will drop, the app will be backgrounded mid-ad, and the connection will die, and make sure that in every case the player is treated fairly: rewarded when they earned it, returned cleanly to a working game when they did not. Build the reward path to reconcile across launches so an interruption delays a reward rather than denying it, and test that reconciliation explicitly.

Re-run the full ad test matrix whenever you update the ad SDK, because ad networks ship breaking changes and new edge cases constantly, and a mediation update can silently change callback behavior. The studios that monetize with rewarded ads sustainably are the ones that treat the reward deal as sacred and the ad SDK as untrusted, testing the failure paths far more than the happy one. Get it right and rewarded ads become a feature players seek out, get it wrong and every dropped reward teaches players that your ads are a waste of time, which kills the engagement loop the ads were meant to create.

A player who watched a rewarded ad must always get the reward. Test the whole lifecycle, treat no-fill as normal, and reconcile interrupted rewards on next launch.