A push notification is a message that pops up on a mobile device. App publishers can send them at any time; users don’t have to be in the app or using their devices to receive them. They can do a lot of things; for example, they can show the latest sports scores, get a user to take an action, such as downloading a coupon, or let a user know about an event, such as a flash sale or weather updates.

Push notifications look like SMS text messages and mobile alerts, but they only reach users who have installed the concerned app. Each mobile platform has support for push notifications — iOS, Android, Windows and BlackBerry all have their own services.

 Fig.1 : Push Notification in iOS

Fig.2 : Push Notification in Android

But all platforms use different mechanism for “pushing” these type of notifications from the back-end.

Let’s take up Android for example. There are a lot of services offering push notifications on Android. The majority  are based on Google Cloud Messaging (GCM), Firebase Cloud Messaging (FCM), etc.

In case of GCM integration, the following steps take place in sequence :

1. An Android device sends a sender ID and application ID to GCM server for registration.
2. Upon successful registration, GCM server issues registration ID to Android device.
3. After receiving registration ID, the device will send the registration ID to your server.
4. Your server will store the registration ID in the database for later use.

Fig.3 : GCM mechanism

For FCM integration also, things work in the same way but there are a few differences :

• If a push notification was opened on one device, it will vanish from all other devices. When we go to our tablet we don’t want to see “new” notifications that we already read on our phone a few hours ago.
• Devices can exchange pushes with each other by sending them to the server with a notification key. This lets you synchronize actions, like alerts on your multiple mobile devices.

FCM is the new and advanced version of GCM and Google strongly recommends using FCM in new apps and to migrate GCM to FCM in the already existing apps.

In case of iOS, the notification of sending a push message is a little different. A middleman, APNs (Apple Push Notification service) is involved.

These are the steps for delivering a push notification in iOS:

1. iOS requests a device token from Apple Push Notification service (APNs).
2. The app receives the token, which functions as the address to send a push notification to.
3. The app sends the token of the device to the app server.
4. When prompted, the server will send a push notification with a device token to the APNS.
5. APNs will send a push notification to the user’s device.

Fig.4 : Push Notifications mechanism in iOS

The APNs token might change in the following cases :

• If the user restores backup data to a new device
• User re-installs the operating system

The FCM registration token may change when:

• The app deletes Instance ID (Instance ID provides a unique ID per instance of your apps. Instance ID provides a simple API to generate security tokens that authorize third parties to access your app’s server side managed resources. Use these tokens now to authorize push messages for your apps via GCM or FCM)
• The app is restored on a new device
• The user uninstalls/reinstall the app
• The user clears app data.

In case the APNs or the FCM token is changed, the entire process is repeated again.

Some test cases you can use for testing the push notification feature from mobile end are :

Test Case	Expected Result
User receives a notification when device is locked and app is in background	Should receive a push notification regarding the same
User receives a notification when device is locked and app is in foreground	Should receive a push notification regarding the same
User receives a notification when app is in background	Should receive a push notification regarding the same
User receives a notification when app is in foreground	Should receive a push notification regarding the same (Android only)
User receives a notification when app is in foreground	Should receive a toast/alert regarding the same (iOS only)
User receives a notification when app is in background and another app is running in foreground	Should receive a push notification regarding the same
User taps on a notification	The app should open and the user should be navigated to the respective screen
User receives a push notification	There should be sound and vibration
User receives multiple push notifications	All the notifications should be displayed in the notification panel with the latest being on top
User taps on a notification	The push should be removed from the notification panel
User receives the same notifications more than once	For every new push, a new notification should be shown
User is not logged in the app	Should not receive any push notification
The language of the device is not English (If app does not support any other language)	User should still receive the push and in English
The language of the device is not English (If app supports that language)	User should receive the push in the selected language
User taps on a notification and there is no internet connection	Should be notified about it
User taps on a notification and there is a server connection failure	Should be notified about it
Push Notification has a title	The title should not be in ellipsis form in any language (if multiple languages are supported)

Scenarios to check for Android Push Notification process :

SNo	Test Scenarios
Push Notification Registration
1	To check that on first launch of app, proper token exchange with FCM and server takes place
2	To check that on server connection failure during token registration on server, retry action is being performed
3	To check that registration is successful with proper token and is logged in database (Check in DB using the query “Select * from table_name;”)
4	To check that when connection is broken and app app could not communicate with FCM, retry action needs to be performed.

Scenarios to check for iOS Push Notification process :

SNo	Test Scenarios
Push Notification Registration
1	To check that on first launch of app, proper token exchange with APNS, FCM and server takes place
2	To check that on second launch of app, proper token exchange with APNS, FCM and server takes place
3	To check that on server connection failure during token registration on server, retry action is being performed (Check in DB using the query “Select * from table_name;”)
4	To check that registration is successful with proper token and is logged in database (Check in DB using the query “Select * from table_name;”)
5	To check that when old APNS token is received, FCM server is not hit
6	To check that when connection is broken and app is trying to communicate with APNS, retry action needs to be performed
7	To check that when connection is broken and app is trying to send APNS token to the FCM, retry action needs to be performed on next app launch