Push notification testing verifies that your app sends, receives, displays, and responds to notifications correctly across iOS and Android. That sounds simple, but notifications touch every layer of the mobile stack: your backend, the push delivery service (APNs or FCM), the device OS, the notification tray, and your app's deep link handling.
What should you test when testing push notifications?
Push notification testing covers five dimensions. Most teams test only the first one.
Teams that only test delivery miss the bugs users actually experience. A notification can arrive fine but open the wrong screen, show a truncated title, or crash the app when tapped from a killed state.
How do you test push notifications on iOS?
iOS push notification testing has a platform-specific wrinkle: the iOS Simulator has limited push support, and real device testing requires proper provisioning.
Testing push notifications on iOS Simulator:
Since Xcode 11.4, the iOS Simulator supports simulated push notifications. You create a JSON payload file and drag it onto the simulator, or use the command line:
xcrun simctl push booted com.yourapp.bundleid notification.jsonThe payload file looks like this:
{
"aps": {
"alert": {
"title": "Your order shipped",
"body": "Order #1234 is on its way"
},
"sound": "default",
"badge": 1
},
"deeplink": "yourapp://orders/1234"
}
Simulator limitations to keep in mind:
- No sound or vibration feedback
- No interaction with the notification (you can't test tap behavior in the simulator reliably)
- Doesn't test actual APNs delivery (the push doesn't go through Apple's servers)
- Doesn't support rich media attachments the same way real devices do
For real device testing, you need an Apple Push Notification service (APNs) certificate or authentication key. The apple push notification console in the Apple Developer portal lets you configure push credentials. Then use a tool like the PushNotifications app or Postman to send test pushes directly to your device token.
Key iOS push testing scenarios:
- Permission prompt handling (first launch, denied, accepted)
- Notification display with and without images
- Tap behavior from lock screen, notification center, and banner
- Deep link routing to the correct screen
- Badge count updates
- Silent notifications (background content fetch)
- Notification grouping and threading
How do you test push notifications on Android?
Android push notification testing is more flexible than iOS because emulators fully support push through Firebase Cloud Messaging (FCM). You don't need special provisioning.
Sending test pushes on Android:
Use the FCM console to send a notification test online directly to your device or emulator. You'll need the device's FCM registration token, which your app logs during initialization.
For API level testing, send a POST request to the FCM API with your push notification payload:
curl -X POST https://fcm.googleapis.com/fcm/send \
-H "Authorization: key=YOUR_SERVER_KEY" \
-H "Content-Type: application/json" \
-d '{
"to": "DEVICE_TOKEN",
"notification": {
"title": "Your order shipped",
"body": "Order #1234 is on its way"
},
"data": {
"deeplink": "yourapp://orders/1234"
}
}'Android specific testing challenges:
Android OEM skins handle notifications differently. This is the part most testing guides skip:
- Samsung OneUI: groups notifications aggressively, may suppress badges on some models
- Xiaomi MIUI: requires explicit permission for notification badges and floating notifications
- OnePlus OxygenOS/ColorOS: battery optimization can delay or block background notifications
- Huawei EMUI: requires Huawei Push Kit alongside FCM for Chinese market devices
A push notification tester who only validates on a Pixel device misses these OEM-specific behaviors. Your testing matrix should include at least one Samsung, one Xiaomi (if your user base includes Chinese or Indian markets), and a Pixel as the reference device.
How do you automate push notification testing?
Manual push testing doesn't scale. Sending a test push, visually checking the notification, tapping it, and verifying the deep link takes 3 to 5 minutes per scenario. With 10 scenarios across 5 devices, that's 4 hours of manual testing per release.
Automating push notification testing is hard because notifications are system-level UI. Your test needs to:
- Trigger the push (call your backend API or FCM/APNs directly)
- Wait for the notification to appear in the notification tray
- Interact with the notification (tap, swipe, expand)
- Verify the app opens to the correct screen with the right data
Steps 1 and 4 are straightforward. Steps 2 and 3 are where automation frameworks struggle.
UI Automator can interact with the Android notification tray because it has system-level access. You can open the notification shade, find a notification by its text, and tap it. But the interaction depends on selectors, and notification tray layouts differ across Android versions and OEM skins.
On iOS, XCUITest has limited support for notification interaction. You can access the notification center through app.springboard, but the APIs are fragile and undocumented.
Drizz handles push notification testing differently. Because Vision AI sees the screen the way a human does, it can interact with notifications regardless of the OS version or OEM skin. A test that says "Wait for notification with text 'Your order shipped', tap on it, validate order details screen shows Order #1234" works across Samsung, Pixel, and iPhone without device-specific selectors.
This is one of the testing scenarios where vision-based testing has a clear advantage over selector-based automation, because system-level UI (notification tray, permission dialogs, system alerts) is the hardest to automate with traditional tools.
What does a complete push notification testing matrix look like?
Multiply this matrix by the number of notification types your app sends (promotional, transactional, system alerts, social) and the number of device configurations in your matrix. A typical mobile app has 5 to 10 notification types. Testing each manually across 4 app states and 6 devices is over 100 test runs.
This is why automating push notification testing matters. Without automation, teams either skip most of the matrix (and ship notification bugs) or spend days testing manually before each release.
What does a real before and after look like?
A social media app team had 8 notification types (new follower, message, comment, like, mention, live stream, story reply, group invite). Before each release, one QA engineer spent a full day manually testing notifications across 3 devices (iPhone 15, Pixel 8, Samsung S24).
They covered delivery and basic tap behavior but skipped the killed app state, skipped rich media rendering, and only tested deep links for 2 of the 8 notification types. After a release, users reported that the "live stream" notification opened the home feed instead of the live stream. The bug existed for two weeks before they caught it.
After switching to automated push testing with Drizz:
- Each notification type has a test that triggers the push, waits for it, taps it, and validates the destination screen
- Tests run across all 4 app states (foreground, background, killed, lock screen)
- Tests run on 6 devices nightly (iPhone 15, iPhone SE, Pixel 8, Samsung S24, Xiaomi 14, OnePlus 12)
- The full push notification suite (48 tests) runs in 90 minutes
- The QA engineer shifted from manual notification testing to writing new tests for edge cases (expired deep links, notifications for deleted content, rate-limited notifications)
They catch notification bugs before release because the automation covers the full matrix that manual testing couldn't.
How should you structure your push notification testing?
Start with the highest-risk notification types. For most apps, that's the notification your users tap most often and the one that drives the most engagement or revenue.
Build your testing approach in layers:
- API-level tests verify that your backend generates the correct payload (correct title, body, deep link URL, custom data). Run these on every merge. They're fast and catch payload bugs early.
- Delivery tests verify that the push reaches the device through FCM or APNs. Run these on staging with a push notification console or the FCM/APNs API. These catch configuration and certificate issues.
- Interaction tests verify the full flow: notification arrives, user taps it, app opens to the right screen with the right data. Run these on real devices nightly. These catch the bugs that users actually experience. Tools like Drizz automate this layer with Vision AI, covering web push notification flows and mobile push flows in the same test infrastructure.
For teams that also support web push notifications, the payload structure is different (web push uses the Web Push Protocol and service workers). The testing principle is the same: verify delivery, display, and interaction. But web push notification testing happens in the browser, not on a device.
How do you test push notifications on iOS?
Use the iOS Simulator for basic payload testing with xcrun simctl push, but test tap behavior and deep links on real devices. You need an APNs certificate or authentication key to send pushes to real devices. Test across all app states (foreground, background, killed) and verify permission prompt handling.
How do you test push notifications on Android?
Use Firebase Cloud Messaging (FCM) console to send test pushes to your device or emulator. Android emulators fully support push notifications. Test on at least one Samsung and one Pixel device because OEM skins (OneUI, MIUI, ColorOS) handle notification display and battery optimization differently.
Can you test push notifications in the iOS Simulator?
Yes, since Xcode 11.4. Testing push notifications ios simulator is possible using a JSON payload file and the xcrun simctl push command. You can test push notifications ios simulator setups for basic payload validation, but simulators don't test real APNs delivery, don't support notification tap interactions reliably, and miss rich media rendering issues. For ios test push notifications simulator coverage of actual interaction behavior, use real devices.
How do you automate push notification testing?
Trigger the push via your backend API or FCM/APNs, wait for it to appear on the device, interact with it (tap, swipe), and verify the app opens correctly. Traditional tools like UI Automator can access the notification tray on Android but struggle with OEM differences. Vision AI tools like Drizz automate the full flow by seeing and tapping notifications visually.
What is the hardest part of push notification testing?
The hardest part is testing notification interaction across different app states and devices. A notification might deliver fine but crash the app when tapped from a killed state, or open the wrong screen on a Samsung device. This interaction testing is what most teams skip and where most notification bugs live.
Should you test web push notifications differently from mobile push?
Web push notifications use a different delivery mechanism (Web Push Protocol, service workers) but the testing principles are the same: verify delivery, display, and tap behavior. Web push testing happens in the browser. Mobile push testing happens on devices. If your app supports both, test each channel separately because the payload formats and display behavior differ.
