Push notification testing: what usually goes wrong

Push is deceptively simple to demo — the notification arrives, you tap it, the app opens — and deceptively easy to ship broken, because that demo only ever runs with the app in one state. Real users get notifications with the app foregrounded, backgrounded, and fully killed, with permission granted or denied, on a flaky network, sometimes by the dozen. Each of those is a different code path, and the ones nobody tests are the ones that break. This is the deep dive on the notification line item from my mobile smoke test.

The three app states (test all three)

The single biggest gap: a notification behaves differently depending on the app's state when it arrives, and most testing only covers one.

• Foreground: app open and active. Many platforms don't show a system banner by default here — the app has to handle the payload and decide what to display. Does it? Or does the notification silently vanish because the foreground case was never coded?
• Background: app open but not in focus. The system banner usually shows; tapping should resume the app to the right place.
• Killed / not running: app fully closed. Tapping must cold-start the app and still route to the right screen. This is the most commonly broken case — the deep-link data has to survive a full launch, and frequently it gets dropped, dumping the user on the home screen instead.

Deep-linking: did it land in the right place?

A notification almost always means "come look at this" — a specific message, order, or screen. Tapping it should deep-link straight there, not just open the app. Test that the destination is correct from all three states (especially killed), and the edge cases: tapping a notification for content that was since deleted, or that belongs to a different logged-in user than the one who's now active.

Permissions: granted, denied, revoked

• Denied: the user declined notification permission. Does the app degrade gracefully, or assume it has permission and break / nag endlessly?
• Revoked later: permission granted, then turned off in system settings while the app is backgrounded. Does the app notice on resume?
• Re-prompt behaviour: does the app handle "denied once" sensibly (most platforms won't let you re-prompt), pointing users to settings instead of silently failing?

Content, timing, and volume

• Rendering: long titles, emoji, other languages, missing images — does the notification truncate cleanly or break?
• Stale content: a notification about an order that's since changed — does tapping show current state, or the stale snapshot from when it was sent?
• Badges and counts: does the app badge increment correctly, and clear when the user reads the content? A badge that never clears is a common, annoying bug.
• Volume / grouping: fire several at once — do they group sensibly or spam the tray? Does acting on one clear the rest appropriately?

Don't forget the send side

If QA can reach it, check why a notification fires: the right trigger, the right user, the right timing (not 3am), and not duplicated (the same event sending twice). A notification that's correct but sent to the wrong user is both a bug and a privacy issue.

Where this fits

Push is one of the mobile-specific risks web-first teams miss; this is the focused pass for it, part of the broader mobile smoke test. The common bugs library catalogues notification defects, and the tools directory covers mobile automation.

Push notification pass

• Notification handled correctly with the app foregrounded, backgrounded, AND killed
• Tapping deep-links to the right screen from all three states (especially killed/cold-start)
• Denied and later-revoked permission handled gracefully
• Content renders (long text, emoji, missing image); stale content shows current state on tap
• Badge increments and CLEARS when content is read; volume/grouping is sane
• Send side: right trigger, right user, right timing, no duplicates