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.