# 6. Notification Settings — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: notification_settings.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature,
  expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 6.1 Configure Default Notification Channels | Channel set: push, email, SMS (enable/disable channels platform-wide) | TC-SA-04-06-001 |
| 6.1 Configure Default Notification Channels | Per-notification-type channel defaults (e.g., security alerts via push + email, receipts via email) | TC-SA-04-06-002 |
| 6.1 Configure Default Notification Channels | User preference within defaults: users can mute or add channels per type, within the configured set | TC-SA-04-06-003 |
| 6.1 Configure Default Notification Channels | Channel capability checks: a channel is used only where the user has it enabled (e.g., SMS only where a phone is verified) | TC-SA-04-06-004 |
| 6.1 Configure Default Notification Channels | Default behavior for new users (the starting preference set) | TC-SA-04-06-005 |
| 6.1 Configure Default Notification Channels | Consistent application across all notification types | TC-SA-04-06-006 |
| 6.1 Configure Default Notification Channels | Audit logging of channel configuration changes | TC-SA-04-06-007 |
| 6.1 Configure Default Notification Channels | Rule: a channel is used only where it is enabled platform-wide and the user has the capability (e.g., a verified phone for SMS) | TC-SA-04-06-004 |
| 6.1 Configure Default Notification Channels | Rule: user preferences operate within the configured defaults: a user can mute or add channels per type, but policy-critical channels (e.g., security alerts) are kept per the configuration | TC-SA-04-06-008 |
| 6.1 Configure Default Notification Channels | Rule: the new-user default ensures a fresh account is notified appropriately without manual setup | TC-SA-04-06-005 |
| 6.1 Configure Default Notification Channels | Rule: the per-type defaults are consistent across the platform; a notification type always uses its configured channels | TC-SA-04-06-006 |
| 6.1 Configure Default Notification Channels | Rule: a channel failure (e.g., an email bounce) is handled per the delivery rules (retry, fallback where configured) | TC-SA-04-06-009 |
| 6.1 Configure Default Notification Channels | Rule: channel configuration changes are audit-logged with the acting admin and timestamp | TC-SA-04-06-007 |
| 6.2 Configure Alert Types and Thresholds | Alert type catalog: the alert types (security, usage, system, business) with their definitions | TC-SA-04-06-010 |
| 6.2 Configure Alert Types and Thresholds | Threshold configuration per alert type (the condition that triggers it) | TC-SA-04-06-011 |
| 6.2 Configure Alert Types and Thresholds | Alert recipients: who receives each alert type (Super Admin, specific roles) | TC-SA-04-06-012 |
| 6.2 Configure Alert Types and Thresholds | Severity levels: the alert's severity and its handling expectation | TC-SA-04-06-013 |
| 6.2 Configure Alert Types and Thresholds | Threshold tuning: adjusting thresholds to balance sensitivity and noise | TC-SA-04-06-014 |
| 6.2 Configure Alert Types and Thresholds | Alert delivery via the configured channels | TC-SA-04-06-015 |
| 6.2 Configure Alert Types and Thresholds | Audit logging of alert configuration changes | TC-SA-04-06-016 |
| 6.2 Configure Alert Types and Thresholds | Rule: an alert fires only when its configured threshold is met; the threshold is the single source of the trigger condition | TC-SA-04-06-017 |
| 6.2 Configure Alert Types and Thresholds | Rule: recipients and severity are configured per type; an alert reaches the right people at the right urgency | TC-SA-04-06-012 |
| 6.2 Configure Alert Types and Thresholds | Rule: threshold tuning is expected: the volume is reviewed and thresholds adjusted to balance sensitivity and noise | TC-SA-04-06-014 |
| 6.2 Configure Alert Types and Thresholds | Rule: alert delivery uses the configured channels; a channel failure is handled per the delivery rules | TC-SA-04-06-015 |
| 6.2 Configure Alert Types and Thresholds | Rule: the alert history records the threshold crossed and the value, so each alert is explainable | TC-SA-04-06-018 |
| 6.2 Configure Alert Types and Thresholds | Rule: alert configuration changes are audit-logged with the acting admin and timestamp | TC-SA-04-06-016 |

## 6.1 Configure Default Notification Channels

### TC-SA-04-06-001 — The channel set allows enabling/disabling push, email, and SMS platform-wide
**Type:** Positive
**Covers:** 6.1 → Channel set: push, email, SMS (enable/disable channels platform-wide)
**Preconditions:** Push and email are enabled; SMS is to be enabled.
**Steps:**
1. Open Notification Settings.
2. Enable SMS in the channel set.
3. Verify SMS is now available platform-wide (where capability exists).
**Expected Result:** SMS is enabled platform-wide — the channel set controls platform-wide availability.
**Priority:** High

### TC-SA-04-06-002 — Per-notification-type channel defaults are configured (e.g., security alerts via push + email, receipts via email)
**Type:** Positive
**Covers:** 6.1 → Per-notification-type channel defaults (e.g., security alerts via push + email, receipts via email)
**Preconditions:** The per-type defaults are: security alerts = push + email, billing receipts = email, course reminders = push.
**Steps:**
1. Configure the three per-type defaults.
2. Trigger a security alert, a billing receipt, and a course reminder.
3. Verify each uses its configured channels.
**Expected Result:** The security alert goes via push + email, the receipt via email, and the reminder via push — the per-type defaults apply.
**Priority:** Critical

### TC-SA-04-06-003 — Users can mute or add channels per type, within the configured set
**Type:** Positive
**Covers:** 6.1 → User preference within defaults: users can mute or add channels per type, within the configured set
**Preconditions:** Course reminders default to push; a user prefers email.
**Steps:**
1. As the user, mute push for course reminders and add email.
2. Trigger a course reminder.
3. Verify it arrives via email (the user's preference within the configured set).
**Expected Result:** The user's preference (email instead of push) is respected within the configured set — the reminder arrives via email.
**Priority:** High

### TC-SA-04-06-004 — Channel capability checks: SMS is used only where the user has a verified phone
**Type:** Negative
**Covers:** 6.1 → Channel capability checks: a channel is used only where the user has it enabled (e.g., SMS only where a phone is verified); Rule: a channel is used only where it is enabled platform-wide and the user has the capability (e.g., a verified phone for SMS)
**Preconditions:** SMS is enabled platform-wide; User A has a verified phone; User B does not.
**Steps:**
1. Trigger an SMS-eligible notification for User A and verify the SMS is sent.
2. Trigger the same notification for User B and verify SMS is not used (no verified phone).
**Expected Result:** User A receives the SMS (verified phone); User B does not (no verified phone) — the capability check is enforced.
**Priority:** Critical

### TC-SA-04-06-005 — The new-user default ensures a fresh account is notified appropriately without manual setup
**Type:** Positive
**Covers:** 6.1 → Default behavior for new users (the starting preference set); Rule: the new-user default ensures a fresh account is notified appropriately without manual setup
**Preconditions:** The new-user default is all default channels on.
**Steps:**
1. Create a new account with no manual preference setup.
2. Trigger a notification for the new user.
3. Verify the notification is delivered via the default channels.
**Expected Result:** The new user is notified appropriately via the default channels without any manual setup.
**Priority:** High

### TC-SA-04-06-006 — The per-type defaults are consistent across the platform; a notification type always uses its configured channels
**Type:** Positive
**Covers:** 6.1 → Consistent application across all notification types; Rule: the per-type defaults are consistent across the platform; a notification type always uses its configured channels
**Preconditions:** Billing receipts default to email; receipts are generated for users across the platform.
**Steps:**
1. Generate billing receipts for 10 users across different contexts.
2. Verify all 10 receipts are delivered via email (the configured channel).
**Expected Result:** All 10 receipts are delivered via email — the per-type default is consistent across the platform.
**Priority:** High

### TC-SA-04-06-007 — Channel configuration changes are audit-logged with the per-type defaults and timestamp
**Type:** Positive
**Covers:** 6.1 → Audit logging of channel configuration changes; Rule: channel configuration changes are audit-logged with the acting admin and timestamp
**Preconditions:** The per-type channel defaults are changed.
**Steps:**
1. Open the audit trail and filter by "notification channel".
2. Verify the entry shows the per-type defaults changed, the acting admin, and the timestamp.
**Expected Result:** The channel configuration change is audit-logged with the per-type defaults, acting admin, and timestamp.
**Priority:** Critical

### TC-SA-04-06-008 — Policy-critical channels (e.g., security alerts) are kept per the configuration; a user cannot mute them
**Type:** Negative
**Covers:** 6.1 → Rule: user preferences operate within the configured defaults: a user can mute or add channels per type, but policy-critical channels (e.g., security alerts) are kept per the configuration
**Preconditions:** Security alerts default to push + email (policy-critical); a user attempts to mute both.
**Steps:**
1. As the user, attempt to mute push and email for security alerts.
2. Verify the policy-critical channels are kept per the configuration.
**Expected Result:** The user cannot mute the policy-critical security-alert channels — they are kept per the configuration.
**Priority:** Critical

### TC-SA-04-06-009 — A channel failure (e.g., an email bounce) is handled per the delivery rules (retry, fallback where configured)
**Type:** Negative
**Covers:** 6.1 → Rule: a channel failure (e.g., an email bounce) is handled per the delivery rules (retry, fallback where configured)
**Preconditions:** An email notification is sent to a bouncing address; a fallback channel is configured.
**Steps:**
1. Send the email notification to the bouncing address.
2. Verify the retry is attempted per the delivery rules.
3. Verify the fallback channel is used where configured.
**Expected Result:** The email bounce is handled per the delivery rules — retry is attempted and the fallback channel is used where configured.
**Priority:** High

## 6.2 Configure Alert Types and Thresholds

### TC-SA-04-06-010 — The alert type catalog lists the alert types (security, usage, system, business) with their definitions
**Type:** Positive
**Covers:** 6.2 → Alert type catalog: the alert types (security, usage, system, business) with their definitions
**Preconditions:** The catalog has security, usage, system, and business alert types.
**Steps:**
1. Open the alert configuration.
2. Verify the catalog lists all four alert types with their definitions.
**Expected Result:** The alert type catalog lists security, usage, system, and business alert types with their definitions.
**Priority:** High

### TC-SA-04-06-011 — Threshold configuration per alert type defines the condition that triggers it
**Type:** Positive
**Covers:** 6.2 → Threshold configuration per alert type (the condition that triggers it)
**Preconditions:** The failed-login alert threshold is set to more than 5 failed logins in 10 minutes.
**Steps:**
1. Set the failed-login threshold to 5 in 10 minutes.
2. Trigger 6 failed logins for an account within 10 minutes.
3. Verify the alert fires.
**Expected Result:** The alert fires when the threshold (5 failed logins in 10 minutes) is met — the threshold is the trigger condition.
**Priority:** Critical

### TC-SA-04-06-012 — Alert recipients and severity are configured per type; an alert reaches the right people at the right urgency
**Type:** Positive
**Covers:** 6.2 → Alert recipients: who receives each alert type (Super Admin, specific roles); Severity levels: the alert's severity and its handling expectation; Rule: recipients and severity are configured per type; an alert reaches the right people at the right urgency
**Preconditions:** The failed-login alert has recipient = Super Admin, severity = high; the usage alert has recipient = the user, severity = low.
**Steps:**
1. Trigger the failed-login alert and verify it reaches the Super Admin at high severity.
2. Trigger the usage alert and verify it reaches the user at low severity.
**Expected Result:** The failed-login alert reaches the Super Admin (high); the usage alert reaches the user (low) — the right people at the right urgency.
**Priority:** Critical

### TC-SA-04-06-013 — Severity levels define the alert's severity and its handling expectation
**Type:** Positive
**Covers:** 6.2 → Severity levels: the alert's severity and its handling expectation
**Preconditions:** Alerts are configured at high, medium, and low severity.
**Steps:**
1. Trigger alerts at each severity level.
2. Verify each alert shows its severity and the handling expectation.
**Expected Result:** Each alert shows its severity and the corresponding handling expectation — the severity levels work.
**Priority:** Medium

### TC-SA-04-06-014 — Threshold tuning: the volume is reviewed and thresholds adjusted to balance sensitivity and noise
**Type:** Positive
**Covers:** 6.2 → Threshold tuning: adjusting thresholds to balance sensitivity and noise; Rule: threshold tuning is expected: the volume is reviewed and thresholds adjusted to balance sensitivity and noise
**Preconditions:** The failed-login alert (5 in 10 minutes) is firing too often (noise).
**Steps:**
1. Review the alert volume and identify the noise.
2. Tune the threshold from 5 to 8 in 10 minutes.
3. Verify the alert volume decreases while real signals are still caught.
**Expected Result:** The threshold is tuned (5 → 8); the noise decreases while real signals are still caught — tuning balances sensitivity and noise.
**Priority:** Medium

### TC-SA-04-06-015 — Alert delivery uses the configured channels; a channel failure is handled per the delivery rules
**Type:** Positive
**Covers:** 6.2 → Alert delivery via the configured channels; Rule: alert delivery uses the configured channels; a channel failure is handled per the delivery rules
**Preconditions:** The failed-login alert delivers via push + email; the email channel fails.
**Steps:**
1. Trigger the failed-login alert.
2. Verify it is delivered via push + email (the configured channels).
3. Simulate an email failure and verify it is handled per the delivery rules.
**Expected Result:** The alert is delivered via the configured channels (push + email); the email failure is handled per the delivery rules.
**Priority:** High

### TC-SA-04-06-016 — Alert configuration changes are audit-logged with the types, thresholds, recipients, and timestamp
**Type:** Positive
**Covers:** 6.2 → Audit logging of alert configuration changes; Rule: alert configuration changes are audit-logged with the acting admin and timestamp
**Preconditions:** The alert types, thresholds, and recipients are changed.
**Steps:**
1. Open the audit trail and filter by "alert".
2. Verify the entry shows the types, thresholds, recipients, the acting admin, and the timestamp.
**Expected Result:** The alert configuration change is audit-logged with the types, thresholds, recipients, acting admin, and timestamp.
**Priority:** Critical

### TC-SA-04-06-017 — An alert fires only when its configured threshold is met; below the threshold, no alert
**Type:** Negative
**Covers:** 6.2 → Rule: an alert fires only when its configured threshold is met; the threshold is the single source of the trigger condition
**Preconditions:** The failed-login threshold is 5 in 10 minutes.
**Steps:**
1. Trigger 4 failed logins for an account within 10 minutes.
2. Verify no alert fires.
**Expected Result:** No alert fires at 4 failed logins (below the threshold of 5) — the alert fires only when the threshold is met.
**Priority:** Critical

### TC-SA-04-06-018 — The alert history records the threshold crossed and the value, so each alert is explainable
**Type:** Positive
**Covers:** 6.2 → Rule: the alert history records the threshold crossed and the value, so each alert is explainable
**Preconditions:** A failed-login alert has fired (6 failed logins, threshold 5).
**Steps:**
1. Open the alert history.
2. Verify the alert shows the type, the threshold crossed (5), the value (6), the recipients, and the time.
**Expected Result:** The alert history shows the type, threshold crossed, value, recipients, and time — the alert is explainable.
**Priority:** High