A push notification is the result of several systems working together, rather than an isolated banner. An event occurs in the product, the backend selects a recipient, a delivery service accepts the message, the device handles it, and the user opens the intended context. Each stage can fail.
QA should distinguish sending, delivery, display, and opening. A successful APNs or FCM response confirms acceptance at the relevant stage, but does not guarantee the user has seen the notification.
The parts of the chain
The chain requires a business event, an addressable app installation, correct registration, server credentials, and permitted device behavior. APNs delivers remote notifications on iOS; Android products often use FCM where suitable for their environment.
A local notification is scheduled by the app on the device, so testing a local reminder does not replace remote delivery testing. A background push also differs from a visible alert: its purpose may be to update data without displaying a banner.
Device registration and accounts
A delivery address belongs to an app installation and platform registration; it is not a permanent user identifier. It can change, so the client and backend must maintain its current association with the account and environment.
Apple requires obtaining the current APNs device token and sending it to the server rather than relying on a locally cached value. For FCM, check the registration model of the SDK in use, identifier updates, and invalid registration handling. Record technical details for the specific integration.
Permission does not guarantee display
An app may have notification permission while channel settings, Focus mode, preview settings, or foreground policy suppress display. On Android, account for runtime permission on applicable OS versions and channel settings.
Define expected behavior for denial, later enablement, and revocation. Denying notifications should not break core app functions unless notifications are explicitly required for the particular scenario.
Name application states precisely
Test the active app, background state, absent process, locked screen, and launch by tapping a message. Backgrounding, system process termination, and user force-closing are different conditions.
Be especially careful with background notification expectations: Apple explicitly states that delivery is not guaranteed and may be throttled by the system. Do not transfer conclusions from one Android state to iOS or promise background execution after every type of closure.
Practical example: an order status change
Consider an "Order ready" notification. Verify the recipient, content, and navigation, beyond the text merely appearing.
- 1.Sign in as test user A, check installation registration, and create an order with a known identifier.
- 2.Move the order to the required status through an authorized method. Record the event time and server send identifier.
- 3.Check the delivery service response and actual notification appearance in the specified device state.
- 4.Tap the message. Expect that exact order to open with its current status, without the navigation itself changing the order again.
- 5.Repeat with an expired session. After sign-in, restore a safe route and recheck access.
- 6.Sign out of A, sign in as B, and repeat the event for A. The new user must not receive details of another user's order.
Separately check a second device belonging to A: multi-device support must follow requirements rather than simply overwriting a single delivery address.
Message lifetime and collapsing
A delayed notification may become irrelevant: an invitation expires, an order finishes, or a call is missed. The product should define validity periods and behavior after reconnection.
FCM supports message lifetime and collapsing certain pending messages; delivery order should not be assumed. Retrieve order state from an authoritative source when opening rather than unconditionally treating old notification text as current truth.
Content and interaction
Check long text, localization, wrapping, icon, sound, badge, and additional actions where supported. Assess sensitive-data requirements alongside lock-screen settings.
Several messages about one object must not create contradictory actions. Repeated taps, stale payloads, deleted objects, and unknown event types need controlled outcomes. A push deep link must pass the same authorization checks as any external link.
Investigating a missing notification
Follow the evidence chain: did the business event occur, was a send created, were the correct account and registration selected, and did the provider accept it? Then examine device connectivity, permissions, restrictions, and app handling.
Useful data includes time with time zone, event identifier, safely masked registration, environment, provider response, and device state. Without these details, a missing banner cannot be confidently attributed to the client or server.
What to include in regression testing
Add reinstallation, registration updates, logout, account switching, multiple devices, and reconnection after message expiry. Check that the backend handles invalid delivery addresses and retries do not become endless sends.
Push must not be the sole way to discover critical state. If a message never arrives, opening the app should still retrieve current data through the intended mechanism. This is a resilience property of the entire product.
Key takeaways for QA
Test push as a chain from event to protected destination screen. Distinguish acceptance, delivery, display, and opening; account for changing registrations and OS restrictions. A good report identifies the broken stage and supporting facts rather than simply stating "the notification never arrived."