Browse the Knowledge Hub32 resources
Test cases
Push notification test cases, starting with the wrong recipient
Twenty six cases covering foreground, background and killed app states, deep link routing, token release on sign out, lock screen privacy, permission states, preferences and unsubscribe, quiet hours, provider failures, deduplication and platform differences.
All 26 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
26 worked examples
Receive a notification with the app in the foreground
TypeFunctionalPriorityHigh- Test data
- A standard notification while the app is open
- Expected result
- Handled in app per the design, either as an in app banner or silently updating the relevant screen, without an unexpected system banner over the content the user is reading.
Receive a notification with the app backgrounded
TypeFunctionalPriorityHigh- Test data
- App backgrounded, screen unlocked
- Expected result
- System notification appears with correct title, body, icon and sound, and tapping it opens the intended screen.
Receive a notification with the app force closed
TypeStatePriorityHigh- Test data
- App swiped away, then a notification sent
- Expected result
- Delivered and tappable, and a cold start routes to the correct screen. This is the state most often left untested and most often broken.
Route a deep link payload from every app state
TypeFunctionalPriorityHigh- Test data
- The same payload delivered in foreground, background and killed states, and while signed out
- Expected result
- Each lands on the intended screen with the intended record. Signed out routes to sign in and then continues to the target rather than dropping it.
Confirm the token is released on sign out
TypeSecurityPriorityHigh- Test data
- Sign in as user A, sign out, sign in as user B on the same device, then send a notification for user A
- Expected result
- User A content never arrives on that device. A token left registered against the previous account is a privacy incident, and it is the single most common defect on this feature.
Handle token refresh and rotation
TypeStatePriorityHigh- Test data
- Force a token refresh, reinstall the app, restore a device backup onto new hardware
- Expected result
- The new token is registered, the stale one is removed, and delivery continues without the user re-enabling anything.
Verify content shown on a locked screen
TypeSecurityPriorityHigh- Test data
- A notification containing personal or financial detail, device locked
- Expected result
- Sensitive values are withheld from the preview per platform privacy settings. A balance, a medical detail or a message body on a lock screen is a disclosure the user did not agree to.
Handle every permission state
TypeSecurityPriorityHigh- Test data
- Not yet asked, granted, denied, denied permanently, and revoked in settings while the app runs
- Expected result
- The app degrades gracefully in each state, never blocks core functionality behind notifications, and does not crash when permission disappears mid session.
Ask for permission at a sensible moment
TypeFunctionalPriorityMedium- Test data
- First launch versus after the user reaches a feature that needs it
- Expected result
- Rationale shown before the system prompt where the platform expects it, because a refusal at first launch is very hard to recover.
Honour notification preferences
TypeFunctionalPriorityHigh- Test data
- Disable one category, disable all, then trigger both a transactional and a marketing notification
- Expected result
- Disabled categories are not sent server side rather than being filtered on the device, and any legally required transactional message follows the documented rule.
Verify unsubscribe and topic changes take effect
TypeStatePriorityHigh- Test data
- Leave a topic or unsubscribe, then trigger a message for it
- Expected result
- Nothing arrives. Continuing to receive messages after unsubscribing is both a trust and a compliance problem.
Verify badge counts
TypeStatePriorityMedium- Test data
- Several notifications, then read some in app and some on another device
- Expected result
- The badge reflects genuine unread items and clears correctly, including when the item was read elsewhere.
Verify grouping and collapse behaviour
TypeFunctionalPriorityMedium- Test data
- Ten notifications for the same conversation or order
- Expected result
- Grouped or collapsed by key so the tray is not flooded, and the latest state replaces earlier messages where that is the intent.
Handle a stale or already resolved notification
TypeStatePriorityHigh- Test data
- Send an alert, resolve the underlying event, then tap the notification an hour later
- Expected result
- The app explains that the item is no longer available rather than opening an empty screen or an error.
Verify quiet hours, focus modes and do not disturb
TypeCompatibilityPriorityMedium- Test data
- Device in do not disturb, plus any in app quiet hours setting
- Expected result
- Respected, with only genuinely time critical alerts using a high priority channel. Abusing priority is how apps get muted permanently.
Verify behaviour across multiple devices for one account
TypeStatePriorityHigh- Test data
- Two phones and a tablet signed into one account
- Expected result
- All registered devices receive the notification, and reading on one clears state on the others per the design.
Verify delivery on a poor or absent connection
TypeStatePriorityHigh- Test data
- Device offline when sent, then reconnected within and beyond the message time to live
- Expected result
- Delivered on reconnection while still valid, silently dropped once expired, and never delivered twice.
Handle a provider error or rejection
TypeNegativePriorityHigh- Test data
- Provider returns an invalid token error, a rate limit response, then a server error
- Expected result
- Invalid tokens are pruned, rate limits are respected with backoff, and failures are retried without duplicating the message.
Verify deduplication and rate limiting
TypeSecurityPriorityHigh- Test data
- Trigger the same event twenty times in a minute
- Expected result
- Duplicate messages are collapsed and a per user ceiling applies. Notification floods are an abuse route and a direct cost.
Verify payload size and truncation
TypeBoundaryPriorityMedium- Test data
- A body far longer than the platform limit, plus an oversized data payload
- Expected result
- Truncated readably rather than rejected by the provider, and the full content is available once the app opens.
Verify localisation and formatting
TypeCompatibilityPriorityMedium- Test data
- Each supported language, plus a name with non Latin characters and a currency amount
- Expected result
- Text is localised to the user preference rather than the server default, and names, dates and amounts render without corruption.
Verify silent and data only messages
TypeFunctionalPriorityMedium- Test data
- A data only push used to sync content
- Expected result
- Handled without showing a banner, respecting platform limits on background execution, and never used to work around a user who disabled notifications.
Verify action buttons on the notification
TypeFunctionalPriorityMedium- Test data
- Each action, including one taken from a locked device
- Expected result
- Actions complete or require authentication where they change data, and the notification updates or dismisses afterwards.
Verify platform differences
TypeCompatibilityPriorityHigh- Test data
- iOS and Android across two OS versions each, plus web push if supported
- Expected result
- Channels, categories, priority and grouping behave per platform, and any feature missing on one platform degrades rather than breaking.
Verify accessibility of notification content
TypeAccessibilityPriorityMedium- Test data
- Screen reader reading a notification, and large text settings
- Expected result
- Content is meaningful when read aloud without relying on an emoji or an icon, and the in app inbox is navigable by keyboard and screen reader.
Verify what is recorded about a notification
TypeSecurityPriorityHigh- Test data
- Inspect logs and analytics after sending a notification containing personal content
- Expected result
- Delivery and open events may be recorded, message content containing personal data is not logged in plain text, and consent state is stored alongside the subscription.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Anything that can deliver one person content to another device, or leak private content onto a lock screen, is High. Everything else is a quality of experience question.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Sign out, sign in as someone else
Three states and one identity change account for almost every push defect worth finding.
Swap accounts on one device
Sign in as A, sign out, sign in as B, then send to A. If it arrives, the token was never released, and that is a privacy incident.
Kill the app first
Force close, then send. The killed state has different delivery and routing behaviour and is the one usually skipped.
Read the lock screen
Send a notification containing a balance or a message body and look at the locked device. Previews leak more than teams expect.
Resolve the event, then tap
Notifications outlive the thing they describe. Tapping a stale one must explain itself, not open an empty screen.
Where push notifications actually go wrong
Token lifecycle is the highest severity gap and the least tested. A device token identifies hardware, not a person, so if sign out does not unregister it and sign in does not rebind it, the next notification for the previous account arrives on a phone now used by someone else. On shared or resold devices, and on any account switch, that is disclosure of one customer content to another. Test it deliberately with two accounts on one device.
The killed app state behaves differently from backgrounded on both platforms, and cold start routing is where deep links break. A payload that opens the right screen from a warm app frequently lands on the home screen from a cold start, or worse, is dropped entirely when the user is signed out. Test all three states against the same payload, including while signed out.
Lock screen previews are a privacy decision that is usually made by default rather than deliberately. Balances, message bodies, medical or legal detail: any of these in a preview is visible to anyone holding the phone. Decide what is safe to show unlocked and assert it.
Finally, preferences and unsubscribe need server side enforcement. Filtering on the device still means the message was sent, which fails an audit and costs money, and a user who unsubscribed and keeps receiving messages will disable notifications permanently rather than complaining.
Suggest an improvementShipping a mobile app?
QAble tests notification flows on real devices across iOS and Android, including token lifecycle, cold start routing and provider failure behaviour.
Mobile app testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- Firebase Cloud Messaging token lifecycle and delivery behaviour on Android.
- Apple Push Notification service authorisation states and delivery behaviour on iOS.
- OWASP MASVS mobile application security verification standard.
Want notifications reaching the right person?
QAble tests mobile apps on real devices with ISTQB-certified engineers. Start with a free QA audit of your app.