QA interview guide
Push notifications are a mobile, backend, and provider workflow at the same time. A strong answer shows you understand OS permissions, device tokens, app lifecycle states, delivery failures, privacy, and whether notifications drive users to the right place.
Write your own answer and compare it with senior QA coverage.
What interviewers expect
Interviewers expect permission prompt states, opt-in and opt-out, token registration and refresh, foreground/background/killed app behavior, deep links, duplicate prevention, quiet hours, localization, timezone, retry logic, delivery failures, and analytics.
Checklist
Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.
Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.
Ready to practice?
Write your own answer and compare it with senior QA coverage.
Answer structure
Common missed areas
Answer template
I would start with permission prompts and token registration, then cover opt-in and opt-out, device token refresh, foreground/background/killed app behavior, deep links, delivery failures, duplicate notifications, quiet hours, localization, timezone, retry logic, analytics, and privacy.
Use it as a structure, then replace the examples with specific checks for the feature you are discussing.
Common weak answer
“I would test valid and invalid cases.”
This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.
Examples
“I would test that the push notification arrives.”
Arrival is only one small part of the flow. It misses permission states, token lifecycle, app lifecycle behavior, deep links, retries, duplicates, quiet hours, privacy, analytics, and platform differences.
“I would test permission prompt states, opt-in and opt-out, notification preferences, quiet hours, device token registration, token refresh, old token invalidation, logout token removal, multiple devices, correct recipient, wrong user not notified, tenant isolation, APNs and FCM configuration, foreground/background/killed app delivery, lock screen privacy, notification center, badge count, read/unread sync, title/body/icon, payload schema and size, localization, timezone, deep links, login required, deleted target, provider timeout, provider outage, invalid token removal, queue retry, duplicate notifications prevented, unauthorized API rejected, XSS escaped, open redirect blocked, delivery analytics, metrics, alerts, audit logs, screen reader support, and iOS/Android behavior.”
FAQ
Start with permission prompt states, opt-in/out, token registration, and correct recipient delivery.
Provider timeout, provider error, provider outage, invalid token, and delivery latency are handled. Queue retry, retry backoff, worker restart, queue restart, malformed payload, and partial send failure are tested.
Sensitive data is not exposed in payload, notification preview, lock screen, logs, analytics, or URLs. Open redirects are blocked and XSS in notification content is escaped.
Device token refresh and logout token removal. Foreground, background, killed app, and lock screen differences. Quiet hours, timezone, localization, and preference rules. Duplicate notifications caused by retries or duplicate events.
Use the interactive how would you test push notifications? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.
What to practice next
Move from reading the guide into interactive practice or a closely related interview topic.
Practice
Write your own answer and compare it with senior QA coverage.