Q10 of 22 · Scenarios
How would you test a notification system (email, push, in-app)?
ScenariosMidscenarionotificationsemailpushfunctional
Short answer
Short answer: Clarify which channels are used, what events trigger notifications, and whether users can configure preferences. Then cover delivery correctness, preference opt-out, deduplication, and behavior at high volume.
Detail
Clarify first
- Which channels are in scope — email, push, in-app, SMS?
- What events trigger notifications, and is each event configurable by the user?
- Is delivery real-time or batched/digest?
- How are failed deliveries handled (retry, log, alert)?
Functional
- Triggering event causes notification delivery to the correct user via the correct channel(s)
- Notification content (subject, body, CTA link) is accurate and contains the right dynamic data
- In-app notification appears in the notification center; unread badge count increments
- Clicking the notification marks it as read, decrements the badge, and navigates to the correct destination
- User preference opt-out is respected — disabling email notifications means no email is sent
Negative / error handling
- Notification sent to a deactivated account → delivery suppressed or logged, no error thrown
- Email delivery fails (bounce, invalid address) → failure logged; retry or alert triggered as per policy
- Push notification sent to an expired device token → token refreshed or removed from the system
- Notification for an event the user did not participate in → not delivered
- Duplicate notifications not sent when a retry occurs (idempotency)
Edge & boundary
- Notification content with special characters, HTML tags, or emoji
- Subject line or push payload at the maximum character limit (preview truncation correct?)
- Timezone-sensitive scheduled notifications sent at the right local time for users in different zones
- High-volume event triggering thousands of notifications simultaneously (e.g., a platform-wide announcement)
Security
- Notification content does not leak another user's data (e.g., order confirmation sent to wrong recipient)
- Unsubscribe tokens are not guessable and are tied to a specific user
- Push notification tokens are correctly scoped to the authenticated user; another user cannot receive notifications intended for you
Performance
- Latency from triggering event to delivery under normal and burst load
Close: automate trigger-to-delivery assertions using a mock SMTP server (MailHog, Mailtrap) or push gateway stub, preference opt-out, and idempotency. Keep manual/exploratory for deliverability under real network conditions and notification rendering across email clients.
// WHAT INTERVIEWERS LOOK FOR
Idempotency on retry (no duplicate notifications), opt-out respected end-to-end, and the token expiry case for push. Mentioning a mock SMTP tool shows practical test setup knowledge.
// COMMON PITFALL
Only checking that a notification is sent after the triggering event. Missing opt-out enforcement, deduplication on retry, high-volume behavior, and the security concern of data leaking across users.