Push notification testing checklist for iOS and Android

For push notification testing, follow one test event from the backend to the phone and through the notification tap. Check who should receive it, whether it appears with the expected content and whether tapping it opens the right record. Repeat with different app states, permissions and accounts, keeping the message reference and timestamps beside each result.

What do you need before sending a test push?

Use a test account, a known app build and a test environment where you can trigger the same event again. Choose one visible notification type, such as an order update. Write down its expected recipient, wording and destination screen. Keep silent background updates in a separate test suite: their success needs a different observation from a visible alert.

Ask the developer to confirm which messaging service, app identifier and environment the build uses. A development build and a store-distributed build may use different push configuration. Make sure the sender targets this installation's current registration. Keep credentials and full device tokens out of shared test notes; use a restricted log reference or masked identifier.

Agree what the app should do when the message arrives while someone is already using it. A banner, an in-app update or a quiet refresh may be deliberate. Apple lets the app choose its foreground notification presentation. On Android, confirm the message type and integration version with the developer; Firebase's receiving guide documents different handling paths. Don't make “a banner always appears” the pass condition.

Which push notification test cases should you run?

Start on a representative iPhone and Android phone if your app supports both. Run these cases against the release candidate, using a fresh event reference for each send so an old notification can't be mistaken for the new one. Add devices and OS versions where notification behaviour has changed or users have reported problems.

“App closed” is too vague for a test result. Pressing Home, swiping the app away and choosing Force stop in Android Settings are different setups. Firebase documents that an Android app force-quit from Settings must be reopened before messages work again; on iOS, swiping away the app affects background message handling. Record the exact action and message type rather than assuming every stopped state should behave alike. Firebase's app-state prerequisites

After switching accounts, trigger another event for A while B is signed in. Check that B doesn't receive A's private alert. This catches a sender still associating the installation with the old account, even when tapping an earlier notification correctly blocks access.

On Android 13 and later, non-exempt notifications require the notification runtime permission. Check the app's overall permission and the relevant notification channel's settings. Use the permission testing checklist for prompt and Settings transitions, with Android's permission guidance as the platform reference.

How do you tell a delivery failure from a display failure?

Keep separate results for the sender, the phone and the tap. For FCM, a returned message ID means the message was accepted for delivery; it doesn't establish that the device received it. A device can be offline and the message can wait or expire. Firebase's message lifespan guide

If the app uses APNs, Apple's Push Notification Console can send a test message and show delivery logs for the development environment. Use it to investigate the receiving path, then repeat the test by triggering the actual backend event. The manual send doesn't check whether your backend selected the right account or honoured its preferences. Apple's Push Notification Console guide

Record the time sent, the provider response and when the notification appeared, including the time zone. Note alert settings, Focus or Do Not Disturb and network state. If no notification appears during the observation window, write “not visible by 14:05” and keep device delivery marked Unknown unless you have evidence for it. A missing banner alone doesn't identify the failing component.

What should happen after tapping the notification?

Choose an observable destination before the run. In a fictional shopping app, “opens the app” is too loose: an order update for order QA-42 should open QA-42 with its current status. Repeat the tap with the app already running and after startup, then with an expired sign-in session. Decide whether the app should ask for sign-in and continue to the order afterwards.

Also try an order the test account can no longer access and one that has been deleted. Agree the unavailable-content message with the product owner; check that the app doesn't display another order as a fallback. If the notification uses the same navigation as a link, the mobile deep link checklist covers the route and sign-in cases in more detail.

What belongs in a push notification bug report?

Give engineering the event and the phone's starting state so they can repeat the failure. Copy these fields into the issue and mark anything you couldn't observe as unknown:

App build, device and OS:
Test environment and messaging service:
Test account alias and intended recipient:
Event/message reference (no credentials or full device token):
Expected notification and destination:

Starting app state and how it was reached:
Permission, channel and alert settings:
Network state:
Steps to trigger the event:

Sent at (with time zone):
Provider response or restricted log reference:
Visible at / not visible by:
Tapped at and actual destination:
Expected result and actual result:
Failures / attempts under these conditions:
Sanitised screenshot, recording or relevant log excerpt:
Unknowns and cases not run:

Capture the notification and the resulting screen when the failure concerns content or navigation. Remove personal information before sharing. For a missing alert, include the observation window and settings instead of a screenshot of an empty home screen. Use the bug report template generator to turn the failed case into a ticket, keeping its message reference beside the evidence.