May 28, 2026

How to Test Push Notifications Properly: A Practical QA Guide for iOS and Android

A modern QA checklist for testing push notifications: cold start, warm start, permissions, notification channels, localization, time zones, logout behavior, multi-account flows, and failure states.

• QA
• Mobile Testing
• Push Notifications
• Android
• iOS
• Testing Strategy
• Mobile QA

Push notifications look simple from the outside.

A message appears. The user taps it. The app opens.

That is the happy path. And in real mobile products, the happy path is only a small part of the story.

Notifications can arrive when the app is closed, running in the background, half-restored from memory, logged out, offline, using another account, or stuck with disabled permissions. They can be delayed, duplicated, localized incorrectly, routed to the wrong screen, or silently blocked by the OS.

That is why push notification testing deserves more than one quick smoke test.

This article is a practical checklist for QA engineers who want to test notifications properly on Android and iOS.

Why notification testing matters

Notifications are part of the product experience.

For some apps they are just reminders. For others they are critical: bank alerts, delivery updates, flight changes, chat messages, security warnings, password reset events, or medical reminders.

Bad notification behavior can quickly damage trust:

• the user taps a notification and lands on the wrong screen;
• the app opens but shows empty content;
• the same notification appears multiple times;
• notifications continue after logout;
• notifications stop working after login;
• the message arrives hours late;
• the notification text is in the wrong language;
• the app gives no guidance after notifications are disabled.

A notification bug is not always just a UI bug. Sometimes it is a backend issue, sometimes a token issue, sometimes a permissions issue, sometimes an app lifecycle issue.

Good QA needs to test the whole chain.

Start with the basic model

Before writing test cases, you need to understand four things:

1. What app state is being tested?
2. What type of notification is being sent?
3. What screen should open after tapping it?
4. What should happen when the app cannot load the content?

Without those answers, notification testing becomes random clicking.

Cold start vs warm start

Mobile apps can be opened from different states.

Cold start

A cold start means the app is not running and has to launch from scratch.

Example:

The user receives a push notification while the app is closed. They tap it. The app starts and should open the correct target screen.

For example, in a mail app, tapping a notification about a new email should open that exact email, not just the inbox.

Warm start

A warm start means the app was already running in the background.

This is often more dangerous.

The app may already have some screen open. It may have cached data. It may have an old navigation state. It may be partially restored from memory. The user taps the notification, and now the app needs to route them to the correct place without breaking the current state.

This is where many notification bugs live.

Typical warm start problems:

• the app opens the previous screen instead of the notification target;
• the app shows a blank detail screen;
• the app crashes during navigation;
• old cached data appears;
• the user session is no longer valid;
• loading state never finishes;
• the app was killed by the OS and behaves like a broken warm start instead of a clean cold start.

Do not only test notifications from a closed app. Test them while the app is backgrounded from different screens.

Local notifications vs remote push notifications

There are two broad types of notifications.

Local notifications

Local notifications are scheduled by the app itself.

For example:

• a reminder at 9:00 AM;
• a timer completion alert;
• a daily habit reminder;
• a calendar-style local alert.

They do not require the server to send a message at the exact moment. The app schedules them and the OS displays them later.

Local notifications are especially sensitive to:

• time zone changes;
• device time changes;
• notification permissions;
• app reinstall behavior;
• logout behavior;
• scheduled notification cleanup.

Remote push notifications

Remote push notifications are sent through a server-side flow.

The app receives them through platform notification services and displays them according to OS rules, app permissions, token registration, channels, categories, and payload data.

Remote notifications are especially sensitive to:

• push token registration;
• login/logout token cleanup;
• backend routing;
• network conditions;
• duplicate sends;
• delayed delivery;
• platform-specific payload differences;
• app version compatibility.

As a QA engineer, do not guess whether a notification is local or remote. Ask the developer or check the implementation notes. Your test strategy depends on it.

Modern platform details QA should not ignore

Notification testing became more platform-specific over time.

On Android, notification behavior depends heavily on runtime permissions, notification channels, app settings, battery behavior, and OEM customizations.

On iOS, you need to pay attention to notification authorization states, Focus modes, Background App Refresh, notification grouping, provisional notifications, and whether the app handles disabled permissions properly.

The main QA point is simple: do not test only inside the app. Test the OS-level settings too.

List view vs detail view

A very common notification bug is incorrect routing.

Most apps have a list-detail structure:

• a list of emails;
• a list of chats;
• a list of orders;
• a list of transactions;
• a list of support tickets;
• a list of notifications inside the app.

The detail view is the specific item the user expects to see after tapping the notification.

Example:

If the notification says “New message from Alex,” tapping it should open that exact conversation.

If the notification says “Your order was delivered,” tapping it should open that exact order.

If the notification says “Suspicious login detected,” tapping it should open the relevant security screen.

Opening the generic list screen is often not enough.

Core push notification test scenarios

1. App is closed: tap notification from cold start

Test that tapping the notification opens the correct screen from a fully closed state.

Check:

• app launches successfully;
• splash/loading flow does not break routing;
• correct detail screen opens;
• correct item is displayed;
• loading state resolves;
• back navigation behaves correctly;
• analytics event is tracked correctly, if required.

Common bug:

The app opens the home screen or list view instead of the detail view.

2. App is backgrounded: tap notification from warm start

Put the app in the background from different screens, then send a notification and tap it.

Test from:

• home screen;
• list screen;
• detail screen;
• settings screen;
• checkout/payment screen;
• login/session-expired state;
• deep nested navigation state.

Check:

• app resumes without visual glitches;
• notification target opens correctly;
• previous screen does not override routing;
• app does not show stale cached content;
• app does not crash or hang.

Common bug:

The app tries to restore the old screen and process the notification at the same time. The result is a crash, blank screen, or wrong screen.

3. Notification is received while the app is open

This is easy to forget.

When the app is in the foreground, the behavior may be different from background delivery.

Check:

• should the notification banner appear or not?
• should an in-app banner appear?
• should the list update automatically?
• should the badge count change?
• should sound/vibration happen?
• should the current screen refresh?

Example:

If the user is already inside a chat, a new message notification may not need a system banner. But the message should appear in the conversation.

Common bug:

The app receives the event but the UI does not update until restart.

4. No internet connection after tapping the notification

This is a critical scenario.

The notification may arrive while the device is online, but the user may tap it later when the device is offline.

Check:

• app does not crash;
• app does not spin forever;
• cached content is shown if available;
• clear offline state is shown if content cannot be loaded;
• retry works after internet returns.

Common bug:

Infinite loader on the detail screen.

5. Duplicate notifications

Send the same event more than once, or trigger the same backend event through realistic user actions.

Check:

• duplicate notifications are not displayed unless expected;
• duplicate taps do not create duplicate records;
• badge count remains correct;
• notification center does not become noisy;
• backend idempotency works.

Common bug:

The same event generates multiple notifications because both client and server trigger it, or because retry logic sends duplicates.

6. Notifications after logout

After logout, the app should not continue sending personal notifications to that user on that device.

Check:

• remote push token is unregistered or detached from the account;
• local scheduled notifications are cleared if they are account-specific;
• sensitive notification content no longer appears;
• tapping old notifications does not expose private data;
• app routes to login when needed.

Common bug:

User logs out, but old account notifications still appear.

This is not just annoying. It can become a privacy issue.

7. Notifications after logging back in

Now test the opposite.

Log out, log back in, and verify that notifications start working again.

Check:

• push token is registered again;
• notification settings are restored or respected;
• notification channels/categories behave correctly;
• notifications do not require app restart to work;
• old account state does not conflict with the new session.

Common bug:

Notifications stop working until the app is restarted or reinstalled.

8. Multiple accounts

If the app supports multiple accounts, test notification routing for each account.

Check:

• notifications arrive for the correct account;
• tapping notification opens the correct account context;
• account switcher does not route to the wrong data;
• disabled notifications for one account do not break another account;
• logout from one account does not unregister notifications for all accounts unless that is expected.

Common bug:

Notifications only work for the first account used on the device.

9. Notification format and content

Notification content should match product requirements.

Check:

• title;
• body;
• sender name;
• subject;
• amount;
• order number;
• preview text;
• icon;
• sound;
• priority;
• badge count;
• action buttons;
• grouping/threading behavior.

Example:

A finance app should not show sensitive transaction details on the lock screen if the product requirement says to hide them.

Common bug:

No one has a clear specification for notification format, so QA only checks that “something appears.”

That is not enough.

10. Time zone and device time changes

This is especially important for local notifications.

Check:

• scheduled reminders update after time zone change;
• notifications trigger at the expected local time;
• daylight saving transitions do not break scheduling;
• manual device time changes are handled reasonably;
• travel scenarios are covered.

Example:

A reminder set for 9:00 AM should not suddenly fire at 3:00 AM after the user changes time zones.

Common bug:

The app schedules based on the original time zone and never recalculates.

11. Localization and language changes

Change the system language and app language if the app supports both.

Check:

• notification title is localized;
• body text is localized;
• action buttons are localized;
• plural forms are correct;
• fallback language is acceptable;
• server-generated text follows the expected locale.

Common bug:

The app UI changes language, but push notifications remain in the old language.

12. Delayed notifications

For time-sensitive flows, delay is a product bug.

Check:

• how fast the notification is expected to arrive;
• whether backend sends it immediately;
• whether platform delivery is delayed;
• whether battery saver or low power mode affects it;
• whether the app correctly handles late notifications.

Examples where delay matters:

• flight updates;
• delivery status;
• login/security alerts;
• financial transactions;
• one-time passwords;
• chat messages.

Common bug:

The app team says “push is unreliable” and never defines an acceptable delivery window. QA should push for a measurable expectation.

13. Notifications do not appear at all

This is the obvious one, but it needs structure.

Check:

• OS notification permission is granted;
• app notification setting is enabled;
• Android notification channel is enabled;
• iOS authorization state allows notifications;
• Focus / Do Not Disturb mode is not hiding the notification;
• device has internet access;
• push token exists;
• backend sent the notification;
• payload is valid;
• app version supports the payload;
• notification is not silently dropped because of missing channel/category/configuration.

Common bug:

QA reports “notification does not appear,” but nobody knows whether the failure is app-side, server-side, OS-side, or test-environment-side.

A good bug report should include enough data to narrow it down.

14. User disables notifications

Users can disable notifications at the OS level.

Test what the app does after that.

Check:

• app detects disabled notifications when needed;
• app explains why notifications are useful;
• app provides a clear path to settings;
• app does not repeatedly annoy the user;
• core app flow still works without notifications.

Common bug:

The app silently fails and gives no instruction on how to enable notifications again.

15. Android notification channels

On modern Android, notification channels matter.

An app may have separate channels for:

• messages;
• marketing;
• reminders;
• security alerts;
• orders;
• background service notifications.

Check:

• notification appears in the correct channel;
• channel name is user-friendly;
• channel importance is correct;
• disabling one channel does not disable unrelated notifications;
• old channels do not break after app update;
• deleted or changed channels are handled carefully.

Common bug:

A critical notification is sent through a low-priority or disabled channel.

16. Android notification permission

On newer Android versions, notification permission is not something QA can ignore.

Check:

• first launch permission flow;
• denied permission behavior;
• “Don’t ask again” style behavior where applicable;
• upgrade from older app versions;
• reinstall behavior;
• app settings after denial;
• in-app explanation before asking permission.

Common bug:

The app assumes notifications are enabled, but the user denied permission during onboarding.

17. iOS notification authorization states

On iOS, test more than “allowed” and “blocked.”

Check:

• not determined;
• denied;
• authorized;
• provisional authorization if used;
• critical alerts if the product uses them;
• notification previews on lock screen;
• Focus mode behavior;
• Background App Refresh impact.

Common bug:

The app treats every non-authorized state the same and gives poor guidance to the user.

What a strong notification bug report should include

A weak report says:

Push notification does not work.

A useful report says:

• platform and OS version;
• app version/build number;
• device model;
• account type;
• notification type;
• local or remote notification;
• app state: foreground, background, killed;
• permission state;
• Android channel or iOS authorization state;
• network condition;
• exact payload or backend event id if available;
• expected result;
• actual result;
• screen recording or screenshots;
• logs if available;
• whether the issue is reproducible.

This saves time for everyone.

Practical QA checklist

Use this as a fast checklist before release:

• Cold start notification opens the correct detail screen.
• Warm start notification works from multiple app screens.
• Foreground notification behavior matches product rules.
• Offline tap behavior is handled.
• Duplicate notifications are not shown.
• Notifications stop after logout.
• Notifications resume after login.
• Multi-account routing works.
• Notification format matches specification.
• Notification content is localized.
• Time zone changes are handled.
• Delays are within acceptable limits.
• Disabled permissions are handled gracefully.
• Android channels are configured correctly.
• Android notification permission is tested.
• iOS authorization states are tested.
• Focus / Do Not Disturb behavior is understood.
• Badge counts are correct.
• Tapping old notifications is safe.
• Sensitive data is not exposed on the lock screen.
• Bug reports include enough technical detail.

Conclusion

Push notification testing is not just checking whether a banner appears.

Real notification testing is about app lifecycle, permissions, routing, backend events, OS behavior, localization, account state, privacy, and failure handling.

The most dangerous bugs often happen outside the happy path:

• app in background;
• app killed by the OS;
• user logged out;
• user switched accounts;
• notification permission denied;
• device offline;
• time zone changed;
• old notification tapped later.

That is why QA should test notifications as a full product flow, not as a small UI feature.

A good notification system feels invisible when it works. But when it breaks, users notice immediately.