# 5. Integration Monitoring — Test Cases

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

## Test Execution Policy

- Zero tolerance: any deviation from the documented behavior is a defect.
- Every failed test is logged with a Bug ID, the feature, the sub-feature, the expected vs actual result, and the severity; 100% of bugs are fixed before the group passes.
- 100% pass rate is required for the group to be marked complete.

## Coverage Matrix

| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 5.1 Connection Health Monitoring | Health status per integration (healthy, degraded, down) | TC-SA-INT-25-001 |
| 5.1 Connection Health Monitoring | Health check frequency and method | TC-SA-INT-25-002 |
| 5.1 Connection Health Monitoring | Credential expiry warnings | TC-SA-INT-25-003 |
| 5.1 Connection Health Monitoring | Health dashboard (all integrations) | TC-SA-INT-25-004 |
| 5.1 Connection Health Monitoring | Rule: consecutive failures → down, alerted | TC-SA-INT-25-005 |
| 5.1 Connection Health Monitoring | Rule: expiry within window → warning | TC-SA-INT-25-006 |
| 5.1 Connection Health Monitoring | Rule: intermittent failures → degraded with rate | TC-SA-INT-25-007 |
| 5.1 Connection Health Monitoring | Rule: recovery → healthy, recovery event logged | TC-SA-INT-25-008 |
| 5.1 Connection Health Monitoring | Rule: auth health check is read-only | TC-SA-INT-25-009 |
| 5.1 Connection Health Monitoring | Audit logging of connection health monitoring | TC-SA-INT-25-010 |
| 5.2 Sync Status Tracking | Last sync time and duration | TC-SA-INT-26-001 |
| 5.2 Sync Status Tracking | Records synced (added, updated, removed, skipped) | TC-SA-INT-26-002 |
| 5.2 Sync Status Tracking | Pending/backlog count | TC-SA-INT-26-003 |
| 5.2 Sync Status Tracking | Sync history (per run) | TC-SA-INT-26-004 |
| 5.2 Sync Status Tracking | Rule: slow sync flagged | TC-SA-INT-26-005 |
| 5.2 Sync Status Tracking | Rule: backlog beyond threshold → alert | TC-SA-INT-26-006 |
| 5.2 Sync Status Tracking | Rule: skipped record counted with reason | TC-SA-INT-26-007 |
| 5.2 Sync Status Tracking | Rule: history entry immutable | TC-SA-INT-26-008 |
| 5.2 Sync Status Tracking | Rule: manual run distinguished from automated | TC-SA-INT-26-009 |
| 5.2 Sync Status Tracking | Audit logging of sync status tracking | TC-SA-INT-26-010 |
| 5.3 Error Logging & Alerting | Error log (timestamp, integration, type, message, record) | TC-SA-INT-27-001 |
| 5.3 Error Logging & Alerting | Error classification (transient, permanent, auth, network) | TC-SA-INT-27-002 |
| 5.3 Error Logging & Alerting | Retry tracking (attempts, backoff, outcome) | TC-SA-INT-27-003 |
| 5.3 Error Logging & Alerting | Alert rules (thresholds, severity, channel) | TC-SA-INT-27-004 |
| 5.3 Error Logging & Alerting | Dead-letter queue (failed items) | TC-SA-INT-27-005 |
| 5.3 Error Logging & Alerting | Rule: transient retried, permanent → dead-letter | TC-SA-INT-27-006 |
| 5.3 Error Logging & Alerting | Rule: auth error suspends, high-severity alert | TC-SA-INT-27-007 |
| 5.3 Error Logging & Alerting | Rule: alert only at threshold (no spam) | TC-SA-INT-27-008 |
| 5.3 Error Logging & Alerting | Rule: reprocessed item removed from queue | TC-SA-INT-27-009 |
| 5.3 Error Logging & Alerting | Rule: repeated pattern grouped into one alert | TC-SA-INT-27-010 |
| 5.3 Error Logging & Alerting | Audit logging of error logging & alerting | TC-SA-INT-27-011 |
| 5.4 Data Consistency Checks | Check scope (enrollment, grades, demographics, payments) | TC-SA-INT-28-001 |
| 5.4 Data Consistency Checks | Check frequency (scheduled, on-demand) | TC-SA-INT-28-002 |
| 5.4 Data Consistency Checks | Mismatch detection (field-level) | TC-SA-INT-28-003 |
| 5.4 Data Consistency Checks | Reconciliation action (auto-fix, flag, report) | TC-SA-INT-28-004 |
| 5.4 Data Consistency Checks | Consistency report (found, resolved, outstanding) | TC-SA-INT-28-005 |
| 5.4 Data Consistency Checks | Rule: report only → logged, not changed | TC-SA-INT-28-006 |
| 5.4 Data Consistency Checks | Rule: auto-fix applies source-of-truth, logged | TC-SA-INT-28-007 |
| 5.4 Data Consistency Checks | Rule: unresolvable → flagged for review | TC-SA-INT-28-008 |
| 5.4 Data Consistency Checks | Rule: never deletes records | TC-SA-INT-28-009 |
| 5.4 Data Consistency Checks | Rule: recurring mismatch escalated | TC-SA-INT-28-010 |
| 5.4 Data Consistency Checks | Audit logging of data consistency checks | TC-SA-INT-28-011 |

## 5.1 Connection Health Monitoring

### TC-SA-INT-25-001 — Health status per integration (healthy, degraded, down)
**Type:** Positive
**Covers:** 5.1 → Health status
**Preconditions:** A Super Admin account is active; integrations are connected.
**Steps:**
1. As a Super Admin, open Integrations & APIs → Monitoring → Connection Health.
2. Verify each integration shows a health status (healthy, degraded, down).
**Expected Result:** Health status per integration — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-25-002 — Health check frequency and method
**Type:** Positive
**Covers:** 5.1 → Check frequency and method
**Preconditions:** Connection health monitoring is active.
**Steps:**
1. Set the health check frequency and method (ping, auth check, test call).
2. Verify health checks run per the frequency and method.
**Expected Result:** Health check frequency and method — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-25-003 — Credential expiry warnings
**Type:** Positive
**Covers:** 5.1 → Credential expiry warnings
**Preconditions:** An integration has credentials with an expiry.
**Steps:**
1. Set the credential expiry warning window.
2. Verify a warning is raised before the expiry.
**Expected Result:** Credential expiry warnings — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-25-004 — Health dashboard (all integrations)
**Type:** Positive
**Covers:** 5.1 → Health dashboard
**Preconditions:** Multiple integrations are connected.
**Steps:**
1. Open the health dashboard.
2. Verify all integrations are shown at a glance with their status.
**Expected Result:** Health dashboard — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-25-005 — Rule: consecutive failures → down, alerted
**Type:** Negative
**Covers:** 5.1 → Rule: down detection
**Preconditions:** A connection fails consecutive health checks.
**Steps:**
1. Let the connection fail consecutive health checks.
2. Verify it is marked down and an alert is raised.
**Expected Result:** A connection that fails consecutive health checks is marked down and alerted — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-25-006 — Rule: expiry within window → warning
**Type:** Edge
**Covers:** 5.1 → Rule: expiry warning
**Preconditions:** A credential expires within the warning window.
**Steps:**
1. Wait for the credential to enter the warning window.
2. Verify a warning is raised (not yet an alert).
**Expected Result:** A credential expiring within the warning window raises a warning (not yet an alert) — delivered exactly as documented.
**Priority:** Medium

### TC-SA-INT-25-007 — Rule: intermittent failures → degraded with rate
**Type:** Negative
**Covers:** 5.1 → Rule: degraded detection
**Preconditions:** A connection has intermittent health check failures.
**Steps:**
1. Let the connection fail intermittently.
2. Verify it is marked degraded with the failure rate.
**Expected Result:** A degraded connection (intermittent failures) is marked degraded with the failure rate — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-25-008 — Rule: recovery → healthy, recovery event logged
**Type:** Negative
**Covers:** 5.1 → Rule: recovery
**Preconditions:** A connection recovers after being down.
**Steps:**
1. Let the connection recover.
2. Verify it is marked healthy and a recovery event is logged.
**Expected Result:** A recovered connection is marked healthy and a recovery event is logged — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-25-009 — Rule: auth health check is read-only
**Type:** Negative
**Covers:** 5.1 → Rule: read-only check
**Preconditions:** A health check method requires auth.
**Steps:**
1. Run the auth health check.
2. Verify it uses a read-only test call (no side effects).
**Expected Result:** A health check method that requires auth uses a read-only test call (no side effects) — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-25-010 — Audit logging of connection health monitoring
**Type:** Positive
**Covers:** 5.1 → Audit logging
**Preconditions:** Connection health monitoring configuration changes have been made.
**Steps:**
1. Open the audit trail and filter by connection health monitoring.
2. Verify entries show the setting, the change, and the timestamp.
**Expected Result:** Audit logging of connection health monitoring — delivered exactly as documented.
**Priority:** Critical

## 5.2 Sync Status Tracking

### TC-SA-INT-26-001 — Last sync time and duration
**Type:** Positive
**Covers:** 5.2 → Last sync time and duration
**Preconditions:** A Super Admin is viewing sync status; syncs have run.
**Steps:**
1. Open Monitoring → Sync Status.
2. Verify the last sync time and duration are shown per integration.
**Expected Result:** Last sync time and duration — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-26-002 — Records synced (added, updated, removed, skipped)
**Type:** Positive
**Covers:** 5.2 → Records synced
**Preconditions:** Syncs have run.
**Steps:**
1. Open the sync status for an integration.
2. Verify the records synced counts (added, updated, removed, skipped) are shown.
**Expected Result:** Records synced — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-26-003 — Pending/backlog count
**Type:** Positive
**Covers:** 5.2 → Backlog count
**Preconditions:** Records are waiting to sync.
**Steps:**
1. Open the sync status.
2. Verify the pending/backlog count is shown.
**Expected Result:** Pending/backlog count — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-26-004 — Sync history (per run)
**Type:** Positive
**Covers:** 5.2 → Sync history
**Preconditions:** Multiple sync runs have occurred.
**Steps:**
1. Open the sync history.
2. Verify each run shows start, end, result, and counts.
**Expected Result:** Sync history — delivered exactly as documented.
**Priority:** Medium

### TC-SA-INT-26-005 — Rule: slow sync flagged
**Type:** Negative
**Covers:** 5.2 → Rule: slow sync
**Preconditions:** A sync exceeds the expected duration.
**Steps:**
1. Let a sync run longer than expected.
2. Verify it is flagged as slow.
**Expected Result:** A sync that exceeds the expected duration is flagged as slow — delivered exactly as documented.
**Priority:** Medium

### TC-SA-INT-26-006 — Rule: backlog beyond threshold → alert
**Type:** Negative
**Covers:** 5.2 → Rule: backlog alert
**Preconditions:** The backlog grows beyond the threshold.
**Steps:**
1. Let the backlog grow beyond the threshold.
2. Verify an alert is raised.
**Expected Result:** A backlog growing beyond the threshold raises an alert — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-26-007 — Rule: skipped record counted with reason
**Type:** Negative
**Covers:** 5.2 → Rule: skip reason
**Preconditions:** A sync skips records.
**Steps:**
1. Run a sync that skips records.
2. Verify each skipped record is counted and listed with the skip reason.
**Expected Result:** A skipped record is counted and listed with the skip reason — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-26-008 — Rule: history entry immutable
**Type:** Negative
**Covers:** 5.2 → Rule: immutability
**Preconditions:** A sync run has completed.
**Steps:**
1. Attempt to edit the sync history entry.
2. Verify the entry is immutable (not edited after the run completes).
**Expected Result:** A sync history entry is immutable (not edited after the run completes) — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-26-009 — Rule: manual run distinguished from automated
**Type:** Edge
**Covers:** 5.2 → Rule: run type
**Preconditions:** Both manual and automated sync runs have occurred.
**Steps:**
1. Open the sync history.
2. Verify a manual sync run is distinguished from an automated run.
**Expected Result:** A manual sync run is distinguished from an automated run in the history — delivered exactly as documented.
**Priority:** Medium

### TC-SA-INT-26-010 — Audit logging of sync status tracking
**Type:** Positive
**Covers:** 5.2 → Audit logging
**Preconditions:** Sync status tracking configuration changes have been made.
**Steps:**
1. Open the audit trail and filter by sync status tracking.
2. Verify entries show the setting, the change, and the timestamp.
**Expected Result:** Audit logging of sync status tracking — delivered exactly as documented.
**Priority:** Critical

## 5.3 Error Logging & Alerting

### TC-SA-INT-27-001 — Error log (timestamp, integration, type, message, record)
**Type:** Positive
**Covers:** 5.3 → Error log
**Preconditions:** A Super Admin is viewing errors; integration errors have occurred.
**Steps:**
1. Open Monitoring → Errors & Alerts.
2. Verify the error log shows timestamp, integration, error type, message, and record.
**Expected Result:** Error log — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-27-002 — Error classification (transient, permanent, auth, network)
**Type:** Positive
**Covers:** 5.3 → Error classification
**Preconditions:** Integration errors have occurred.
**Steps:**
1. Review the error log.
2. Verify errors are classified (transient, permanent, auth, network).
**Expected Result:** Error classification — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-27-003 — Retry tracking (attempts, backoff, outcome)
**Type:** Positive
**Covers:** 5.3 → Retry tracking
**Preconditions:** Failed operations have been retried.
**Steps:**
1. Open the retry tracking.
2. Verify it shows attempts, backoff, and final outcome.
**Expected Result:** Retry tracking — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-27-004 — Alert rules (thresholds, severity, channel)
**Type:** Positive
**Covers:** 5.3 → Alert rules
**Preconditions:** A Super Admin is configuring alerting.
**Steps:**
1. Configure the alert rules (thresholds, severity, notification channel).
2. Trigger an alert condition and verify the alert fires per the rules.
**Expected Result:** Alert rules — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-27-005 — Dead-letter queue (failed items)
**Type:** Positive
**Covers:** 5.3 → Dead-letter queue
**Preconditions:** Failed items exist.
**Steps:**
1. Open the dead-letter queue.
2. Verify failed items are listed for manual review.
**Expected Result:** Dead-letter queue — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-27-006 — Rule: transient retried, permanent → dead-letter
**Type:** Negative
**Covers:** 5.3 → Rule: classification handling
**Preconditions:** Both transient and permanent errors occur.
**Steps:**
1. Trigger a transient error and verify it is retried.
2. Trigger a permanent error and verify it is moved to the dead-letter queue (not retried).
**Expected Result:** A transient error is retried; a permanent error is not (moved to dead-letter) — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-27-007 — Rule: auth error suspends, high-severity alert
**Type:** Negative
**Covers:** 5.3 → Rule: auth error
**Preconditions:** An auth error occurs.
**Steps:**
1. Trigger an auth error.
2. Verify the integration is suspended and a high-severity alert is raised.
**Expected Result:** An auth error suspends the integration and raises a high-severity alert — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-27-008 — Rule: alert only at threshold (no spam)
**Type:** Negative
**Covers:** 5.3 → Rule: threshold
**Preconditions:** An alert rule has a threshold.
**Steps:**
1. Generate errors below the threshold and verify no alert fires.
2. Generate errors meeting the threshold and verify the alert fires.
**Expected Result:** An alert fires only when the threshold is met (no alert spam below threshold) — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-27-009 — Rule: reprocessed item removed from queue
**Type:** Negative
**Covers:** 5.3 → Rule: reprocessing
**Preconditions:** A dead-letter item is reprocessed successfully.
**Steps:**
1. Reprocess the dead-letter item.
2. Verify it is removed from the queue on success.
**Expected Result:** A dead-letter item reprocessed successfully is removed from the queue — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-27-010 — Rule: repeated pattern grouped into one alert
**Type:** Edge
**Covers:** 5.3 → Rule: grouping
**Preconditions:** The same error occurs for many records.
**Steps:**
1. Generate the same error across many records.
2. Verify the pattern is grouped into one alert.
**Expected Result:** A repeated error pattern (same error, many records) is grouped into one alert — delivered exactly as documented.
**Priority:** Medium

### TC-SA-INT-27-011 — Audit logging of error logging & alerting
**Type:** Positive
**Covers:** 5.3 → Audit logging
**Preconditions:** Error logging/alerting configuration changes have been made.
**Steps:**
1. Open the audit trail and filter by error logging & alerting.
2. Verify entries show the setting, the change, and the timestamp.
**Expected Result:** Audit logging of error logging & alerting — delivered exactly as documented.
**Priority:** Critical

## 5.4 Data Consistency Checks

### TC-SA-INT-28-001 — Check scope (enrollment, grades, demographics, payments)
**Type:** Positive
**Covers:** 5.4 → Check scope
**Preconditions:** A Super Admin is configuring consistency checks.
**Steps:**
1. Open Monitoring → Data Consistency and set the check scope (enrollment, grades, demographics, payments).
2. Run a check and verify the configured scope is checked.
**Expected Result:** Consistency check scope — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-28-002 — Check frequency (scheduled, on-demand)
**Type:** Positive
**Covers:** 5.4 → Check frequency
**Preconditions:** Consistency checks are configured.
**Steps:**
1. Set the check frequency to scheduled and verify checks run on schedule.
2. Run an on-demand check and verify it runs immediately.
**Expected Result:** Check frequency — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-28-003 — Mismatch detection (field-level)
**Type:** Positive
**Covers:** 5.4 → Mismatch detection
**Preconditions:** A data mismatch exists between the platform and a connected system.
**Steps:**
1. Run a consistency check.
2. Verify the field-level mismatch is detected.
**Expected Result:** Mismatch detection — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-28-004 — Reconciliation action (auto-fix, flag, report)
**Type:** Positive
**Covers:** 5.4 → Reconciliation action
**Preconditions:** Consistency checks are configured.
**Steps:**
1. Set the reconciliation action to auto-fix and verify mismatches are fixed.
2. Set it to flag for review and report only and verify each action applies.
**Expected Result:** Reconciliation action — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-28-005 — Consistency report (found, resolved, outstanding)
**Type:** Positive
**Covers:** 5.4 → Consistency report
**Preconditions:** Consistency checks have run.
**Steps:**
1. Open the consistency report.
2. Verify it shows mismatches found, resolved, and outstanding.
**Expected Result:** Consistency report — delivered exactly as documented.
**Priority:** Medium

### TC-SA-INT-28-006 — Rule: report only → logged, not changed
**Type:** Negative
**Covers:** 5.4 → Rule: report only
**Preconditions:** The reconciliation action is report only; a mismatch exists.
**Steps:**
1. Run the consistency check.
2. Verify the mismatch is logged but not changed.
**Expected Result:** A mismatch with action "report only" is logged but not changed — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-28-007 — Rule: auto-fix applies source-of-truth, logged
**Type:** Negative
**Covers:** 5.4 → Rule: auto-fix
**Preconditions:** The reconciliation action is auto-fix; a mismatch exists.
**Steps:**
1. Run the consistency check.
2. Verify the source-of-truth value is applied and the change is logged.
**Expected Result:** An auto-fix applies the source-of-truth value and logs the change — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-28-008 — Rule: unresolvable → flagged for review
**Type:** Negative
**Covers:** 5.4 → Rule: manual review
**Preconditions:** A mismatch cannot be auto-resolved.
**Steps:**
1. Run the consistency check.
2. Verify the mismatch is flagged for manual review.
**Expected Result:** A mismatch that cannot be auto-resolved is flagged for manual review — delivered exactly as documented.
**Priority:** High

### TC-SA-INT-28-009 — Rule: never deletes records
**Type:** Negative
**Covers:** 5.4 → Rule: no deletion
**Preconditions:** A consistency check finds a record that exists on one side only.
**Steps:**
1. Run the consistency check.
2. Verify the check never deletes records (only updates or flags).
**Expected Result:** A consistency check never deletes records (only updates or flags) — delivered exactly as documented.
**Priority:** Critical

### TC-SA-INT-28-010 — Rule: recurring mismatch escalated
**Type:** Edge
**Covers:** 5.4 → Rule: escalation
**Preconditions:** The same record mismatches across repeated checks.
**Steps:**
1. Run repeated consistency checks on the same mismatched record.
2. Verify the recurring mismatch is escalated.
**Expected Result:** A recurring mismatch (same record, repeated checks) is escalated — delivered exactly as documented.
**Priority:** Medium

### TC-SA-INT-28-011 — Audit logging of data consistency checks
**Type:** Positive
**Covers:** 5.4 → Audit logging
**Preconditions:** Data consistency check configuration changes have been made.
**Steps:**
1. Open the audit trail and filter by data consistency checks.
2. Verify entries show the setting, the change, and the timestamp.
**Expected Result:** Audit logging of data consistency checks — delivered exactly as documented.
**Priority:** Critical
