Test cases for push notifications
Updated 2026-11-13 · 6 min read
These 30 cases use explicit test fixtures and checkable outcomes. Cover normal behavior, boundaries, recovery, security and usability, then adapt the requirements to your product.
How to answer in an interview
Ask which platforms, notification categories, privacy rules and delivery guarantees apply. Separate provider acceptance, device receipt, visible presentation and user interaction. Then test account changes and stale notifications before adding cosmetic cases.
Scope and test data
These 30 cases assume an isolated notification backend with test devices only, transactional and optional marketing categories, authenticated deep links and an in-app activity list. Use synthetic event IDs and content, never real customer messages. Record the app/OS versions, permission state, category settings, expiry policy and measurement targets before each run.
Android documents notification permission behavior for supported OS versions; provider acceptance is not a promise of immediate visible delivery. Firebase documents message lifespan and expiry. Background execution, focus modes and battery restrictions can change observations. Treat an absent banner as a symptom to locate, not automatic proof that the backend failed.
These are proposed manual test cases, not an execution report. Run security and load checks only in an authorised isolated environment. Record agreed limits before execution; a case without its required limit is not ready to pass or fail.
Permission and preferences
| ID | Category | Test case | Expected result |
|---|---|---|---|
| N01 | Functional | Install fresh, trigger the designed permission request and allow | App records the permitted state and a test notification can be presented |
| N02 | Negative | Deny notification permission | App remains usable; it does not claim notifications are enabled |
| N03 | Functional | Enable notifications later through OS settings | Returning to the app reflects the new state and registration is reconciled |
| N04 | Functional | Revoke permission in OS settings | App stops presenting itself as enabled; other app features still work |
| N05 | Functional | Disable marketing while keeping transactional notifications enabled | Marketing test event is suppressed; transactional event follows its own rules |
| N06 | Functional | Disable one supported notification category | That category is suppressed without disabling unrelated categories |
| N07 | Functional | Sign out before generating a private event | Backend no longer targets that signed-out account on this device |
| N08 | Security | Sign in as B on a device previously used by A | B receives no new private notification intended for A |
| N09 | Functional | Register a second device for the same test account | Delivery targets both or the chosen subset exactly as the multi-device policy specifies |
| N10 | Functional | Rotate the registration token in an authorised fixture | Backend uses the new token; stale token is retired without duplicating logical delivery |
Delivery, expiry and interaction
| ID | Category | Test case | Expected result |
|---|---|---|---|
| N11 | Functional | Receive an event with the app in foreground | Configured in-app presentation appears once without duplicate system presentation |
| N12 | Functional | Receive with the app in background and permission enabled | Notification appears according to OS/category policy and opens the intended app state |
| N13 | Compatibility | Receive with the app not running on each supported OS | Observed handling matches the documented platform lifecycle; no universal delivery assumption is used |
| N14 | Functional | Tap a notification targeting an existing authorised item | The correct item opens, not a generic or unrelated screen |
| N15 | Security | Tap a private notification after session expiry | Authentication occurs before private item content is displayed |
| N16 | Negative | Tap a notification whose target has been deleted | A safe unavailable-item screen appears without a crash |
| N17 | Functional | Reconnect a device before message expiry | Eligible pending event is handled under the provider and app delivery policy |
| N18 | Boundary | Reconnect only after the configured message expiry | Expired event is not presented as a new actionable alert |
| N19 | Functional | Receive two updates sharing the configured collapse identity | The resulting notification reflects the documented latest-update policy |
| N20 | Negative | Deliver the same logical event twice through the test harness | Application-owned processing creates one activity entry and no duplicate business action |
Privacy, presentation and operational evidence
| ID | Category | Test case | Expected result |
|---|---|---|---|
| N21 | Security | Receive private content with lock-screen previews disabled | Sensitive body content is hidden according to the privacy configuration |
| N22 | Security | Alter a deep-link resource ID to another account's item | Server denies access even if the app opens the route |
| N23 | Functional | Dismiss a notification without opening it | Dismissal does not falsely mark the underlying item read unless explicitly designed that way |
| N24 | Functional | Open the item in-app before tapping its old notification | Old notification opens current state without repeating a completed action |
| N25 | UI | Send a long title and Hindi body | Truncation remains readable; full authorised content is available after opening |
| N26 | UI | Read and act on a notification using assistive technology | Title and supported actions have useful spoken labels and reachable targets |
| N27 | Compatibility | Repeat with focus mode and battery restrictions on supported devices | Suppression or delay is recorded distinctly from provider rejection |
| N28 | Performance | Measure event-to-receipt on a controlled connected device cohort | Distribution and failures meet the agreed test target; provider acceptance is timed separately |
| N29 | Negative | Return a permanent invalid-token response from the provider stub | Token is retired; backend does not retry it indefinitely |
| N30 | Negative | Return a transient provider failure in the isolated test | Bounded retries follow policy without multiplying activity entries or sending after expiry |
Keep four timestamps separate
Record event creation, provider acceptance, device receipt and open action where instrumentation permits. A provider message ID proves only that stage of the workflow. Missing device telemetry should be reported as missing evidence, not converted into a delivered count.
For the interview follow-up “Can push be guaranteed?”, explain the product's fallback. A time-sensitive item may need an in-app status source because a notification can be delayed or suppressed. Test that source independently rather than promising universal instant delivery.
Downloads
Quick answers
Does a successful provider response mean the user saw the notification?
No. Device connectivity, expiry, permissions and OS presentation rules are separate stages.
Which notification case is most important for privacy?
Account switching on a shared device: an old registration must not deliver the previous account’s private events to the new user.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.