Platform
Docs
Solutions
ContactLog In

5 Must-Have Test Cases for Mobile App Push Notification

Get started sending notifications with Courier in minutes, not days!

We have SDKs in Ruby, Go, Python, Javascript, Node.js, and React.

Sign up

In the QA world, creating test cases with your customer in mind is critical. Many businesses rely on push notifications to engage and retain their audience, so testing and verifying that notifications work as expected is important.

This guide explores five Android push notification test cases that should be included in any test plan and be ready to run in smoke tests. To ensure that users will receive your push notifications when and as intended, you should ensure your test plan can confirm all of the following:

  1. Push notifications work in all states.
  2. Deep links work when clicked.
  3. Notifications work for multiple languages and time zones.
  4. Haptics work as intended.
  5. Customers get push notifications when not logged in.

These test cases mimic scenarios that occur in your customers' daily lives and have a significant impact on your product. In addition, appropriate testing of these cases will ensure good coverage throughout the notification lifecycle and knock off a few edge cases threatening to bypass unnoticed.

1. Push Notifications Work in All States

Verifying that push notifications work in all states is the most basic and most important test case. If you can't verify that push notifications work in common states–e.g., locked, unlocked, app running in background or not–your delivery system has a fatal flaw.

The app you build will be in different states throughout the day. And if you need notifications delivered consistently, your delivery mechanism must work regardless of your app's state.

Most importantly, depending on your business model, push notifications can drive revenue generation. If your customers don't see your notifications, you lose subscribers and potential leads. Getting push notifications is equally important whether the customer's phone is idle or in use, as these states occur consistently throughout the day.

Therefore, if you're part of an Android development team, verifying if a notification is present when a device is unlocked is also recommended and requires minimal code.

For example, you can easily verify Appium Settings for Google notifications:

Appium Push Notification

Simply open your notifications and find the element containing your push notification. Create a true/false statement verifying its existence and run the test:

1 2 3 4 5 6 driver.openNotifications(); WebElement pushNotification = driver.findElement(By.id("android:id/title")); boolean verifyNotification = pushNotification.isDisplayed(); System.out.println(pushNotification.getText()); System.out.println(verifyNotification);

The output is as follows:

Appium Settings

If you're part of a development team, this code works as a simple first pass. Developers can tailor this solution to a specific test case or modify it to a more elegant solution. For example, you could use a page object model (POM) to store Android elements for future use.

As phone states can be both active and passive processes, making sure your push notifications arrive in both states is essential.

Clickable links that redirect customers to web pages, in-app purchases, or third-party software are a major feature of push notifications. These are called deep links and are essential to any thriving business, whether you're an entrepreneur, startup, or corporate conglomerate with millions of users.

For example, consider a push notification created to promote an e-commerce business's latest laptop. A user of the business's app is searching for a new laptop, so they try to open the notification when they receive it, but nothing happens. This poor experience greatly diminishes the likelihood that the user will seek out or ever find the promotion. Imagine this scenario but repeated hundreds—or worse, thousands—of times.

If your links don't work and customers have to jump through hoops to reach your message, your customer retention and conversion will suffer. Users want an easy, uninterrupted mobile experience. So Android development teams should verify deep links work as a core part of their test plan.

3. Notifications Work for Multiple Languages and Time Zones

Unless your customers exclusively live in the same region as your development team or only speak English, you should always test that your push notifications deliver in multiple settings. For example, test how your notifications deliver in German vs. English or if Android differentiates between CST and GMT time zones. Your notifications are typically delivered in different settings via localization. According to Android Developer's resource guide, localization can handle a variety of mediums–i.e., text, audio, numbers, currency, and graphics–depending on your customers' needs.

Checking Multiple Language Support

Functional testing across multiple languages is essential. In the United States, more than forty-three million people (or 13 percent of the population) speak Spanish, so if you're able to test only English-language push notifications, you're leaving yourself vulnerable to errors that affect a huge market.

Thankfully, Android provides the pseudolocales method, a built-in way to test non-English languages on your Android device. It uses a “test to break” approach by simulating characteristics in multiple languages that can cause errors for your app (or, in this instance, push notification). For example, pseudolocales can spot a common problem where different character lengths from other languages work for English-centered UIs but break when they go past the allotted size.

Checking Different Time Zone Support

Even if you decide to limit your business to the United States, push notifications should still be relevant to your users' current geolocation. If your app can't geolocate where the user is, they may get deals or promotions for cities where they no longer live. Ensuring your notifications are adaptable to different time zones is especially important with remote work on the rise. Many people are moving from city to city, state to state, and country to country, so their devices are subject to drastic shifts in time zones.

For example, products specializing in transport (i.e., Lyft or Uber) frequently restrict customers from using deals or promotions during certain times like rush hour, and push notifications are often used to alert customers to when these restrictions apply. So if your notifications are not adaptable to different time zones, your customer could receive these notifications at the wrong time.

Confirming that your notifications will work in various time zones is easy. For example, suppose you want to verify a push notification to a dummy account located in Chicago, which is in Central Standard Time (CST). In that case, you can plug in the TimeZones class and use the built-in method to parse a geolocation. In this instance, you can send the notification itself and validate if the endpoint on the JSON package or API match the user's device.

4. Haptics Work as Intended

Many push notifications contain high-priority messages. For example, emergency broadcasts provide real-time info on extreme weather warnings. Unless your customer sets their phone to silent, their haptics (i.e., notification ringtone or vibration) should trigger when they receive notifications. You don't want customers missing time-sensitive messages for minutes, hours, or even days.

Haptics are essential when it comes to business meetings or alarms. Imagine a mandatory company-wide meeting is issued, but your Android device doesn't emit a ringtone, let alone vibrate. The consequences could range from irritating to disastrous but are completely preventable with functional testing.

When it comes to testing your haptics for push notifications, a go-to messaging solution is Firebase Cloud Messaging (FCM). With it, developers can implement dummy push notifications and run unit tests.

According to Firebase's official documentation, developers can use a wide variety of parameters to test haptics, including timed vibrations and default sound, to boost optimal test coverage for Android push notifications.

For notification ringtones, Firebase implements the FirebaseNotification class. A string property can be parameterized to play a sound when your Android device receives a notification.

If you want to go with a built-in Android solution, RingtoneManager has got you covered and enables you to craft a simple solution in minutes.

5. Customers Get Push Notifications When Not Logged In

Apps often log users out after periods of inactivity. This can be prevented by clicking the Keep Me Logged In button or a variation thereof. However, sometimes that doesn't work for a variety of reasons, including old corrupted cache files or users clearing cache data.

Unless your customer intentionally logged off, you should ensure that they get fresh reminders of promotions, deals, or new products you're offering. This will improve client retention and give them an incentive to return to your brand. Therefore, developers should preempt this problem using the PendingIntent and BroadcastReceiver class.

BroadcastReceiver allows developers to detect system or application events. If, for example, your app's authentication token expires and logs your customer out, BroadcastReceiver is notified.

Once BroadcastReceiver detects the broadcast, developers can execute PendingIntent. PendingIntent grants third-party software permission to execute actions as if you performed them. In this case, PendingIntent runs predefined code (e.g., a push notification) despite your Android system logging your user out or after their processes end. An example of this can be found in a JournalDev article here.

Android vs. iOS Push Notifications

While this article focused on Android devices, many of these principles are just as valid for iOS. However, some key differences should be considered:

  1. When using push notifications on Android, users are given an option to receive notifications after downloading an app. This is in contrast to iOS devices, which don't give users an option until they open the app for the first time.

  2. On Android devices, push notifications remain on the user's lock screen until they have been opened or dismissed. In contrast, on iOS devices, push notifications disappear once the user unlocks their phone.

  3. Android provides a list of notifications when swiping down during a locked state. However, when users swipe down on iOS devices, a list of notifications in chronological order appears on screen.

Are These Essential Test Cases in Your Test Plan?

Whether you're testing an Android or iOS mobile device, your customer's experience always comes first. These scenarios are so common in your customers' daily lives that failure in any of these tests can severely impact your business goals and product quality overall. Therefore, these five test cases should be included in every test plan.

If you want an optimized tool that ensures your push notifications work as intended every time, check out Courier. With Courier, you can scale your push notifications through various channels and mediums effortlessly. Its robust API was built with developers in mind and will make your push notification experience a breeze.

Ready to take your push notification delivery to the next level? Get started with Courier today.

Author: Adam Smock

Get started sending notifications with Courier in minutes, not days!

We have SDKs in Ruby, Go, Python, Javascript, Node.js, and React.

Sign up

View More Guides

Build your first notification in minutes

Send up to 10,000 notifications every month, for free.

Get started for free

Email & push notification

Build your first notification in minutes

Send up to 10,000 notifications every month, for free.

Get started for free

Email & push notification

Platform

Users

Content

Channels

Sending

Workflows

Preferences

Inbox

Workspaces

Observability

API Status

Changelog

© 2024 Courier. All rights reserved.