Push notifications are an important part of our everyday life. Notifications might appear at any point and it even brings anxiety at times. However, this is not the topic of our discussing.
This article has a different purpose: discuss how to test notifications the right way and make QA engineers understand the importance of it on both iOS and Android devices.
This article is intended for QA Engineers who want to plan the best strategy for testing notifications.
Cold and Warm start
Before we dig deeper into notifications there are three concepts that we need to know about: cold/warm start, local/server notifications, and list/detail view.
Every application has two states: stopped or running.
Cold start is a process of loading an application from the very beginning. It means that the application was stopped and the user pressed the icon to launch it. When the app is “cold started” everything loads from scratch and that’s why it takes the longest time to start.
The warm start is a process of “refreshing” an application state after it was running in the background for a while. Warm start usually takes much less time to load since we are essentially just getting the app back from the background and restoring the state.
The catch: Since cold start loads the app from the beginning it minimizes the chances of application appearing and behaving incorrectly. Our job as a QA Engineer to specifically focus on warm starts since this is the “grey area” that developers usually have not enough focus on.
The warm start might bring issues such as:
- The incorrect visual appearance of application layout or specific screen that was loaded before going into the background
- Outdated information due to the app not updating the state while being the in background
- Applications being “killed” due to the lack of memory while being in background (e.g other apps were running and that kicked that application out of the system)
- The user being logged out of the system because of the credentials issue