# 6. Incident Management — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: incident_management.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 Error and Exception Monitoring | Error | TC-SA-24-06-001 |
| 6.1 Error and Exception Monitoring | Type | TC-SA-24-06-002 |
| 6.1 Error and Exception Monitoring | Exception | TC-SA-24-06-003 |
| 6.1 Error and Exception Monitoring | Error status | TC-SA-24-06-004 |
| 6.1 Error and Exception Monitoring | Error count | TC-SA-24-06-005 |
| 6.1 Error and Exception Monitoring | Error period | TC-SA-24-06-006 |
| 6.1 Error and Exception Monitoring | Error view | TC-SA-24-06-007 |
| 6.1 Error and Exception Monitoring | Audit logging of the error and exception monitoring | TC-SA-24-06-008 |
| 6.1 Error and Exception Monitoring | Rule: the error is the fault/failure | TC-SA-24-06-001 |
| 6.1 Error and Exception Monitoring | Rule: the type is the category/class | TC-SA-24-06-002 |
| 6.1 Error and Exception Monitoring | Rule: the exception is the event/anomaly | TC-SA-24-06-003 |
| 6.1 Error and Exception Monitoring | Rule: the error status is the state/control | TC-SA-24-06-004 |
| 6.1 Error and Exception Monitoring | Rule: the errors are visible — monitoring is managed | TC-SA-24-06-007 |
| 6.1 Error and Exception Monitoring | Rule: audit-logged with error, type, and timestamp | TC-SA-24-06-008 |
| 6.2 Alerting on Performance Degradation | Alert | TC-SA-24-06-009 |
| 6.2 Alerting on Performance Degradation | Metric | TC-SA-24-06-010 |
| 6.2 Alerting on Performance Degradation | Threshold | TC-SA-24-06-011 |
| 6.2 Alerting on Performance Degradation | Alert status | TC-SA-24-06-012 |
| 6.2 Alerting on Performance Degradation | Alert count | TC-SA-24-06-013 |
| 6.2 Alerting on Performance Degradation | Alert period | TC-SA-24-06-014 |
| 6.2 Alerting on Performance Degradation | Alert view | TC-SA-24-06-015 |
| 6.2 Alerting on Performance Degradation | Audit logging of the performance degradation alerting | TC-SA-24-06-016 |
| 6.2 Alerting on Performance Degradation | Rule: the alert is the signal/notice | TC-SA-24-06-009 |
| 6.2 Alerting on Performance Degradation | Rule: the metric is the measure/value | TC-SA-24-06-010 |
| 6.2 Alerting on Performance Degradation | Rule: the threshold is the limit/trigger | TC-SA-24-06-011 |
| 6.2 Alerting on Performance Degradation | Rule: the alert status is the state/control | TC-SA-24-06-012 |
| 6.2 Alerting on Performance Degradation | Rule: the degradation is flagged — alerting is managed | TC-SA-24-06-015 |
| 6.2 Alerting on Performance Degradation | Rule: audit-logged with alert, threshold, and timestamp | TC-SA-24-06-016 |
| 6.3 Incident Tracking and Resolution | Incident | TC-SA-24-06-017 |
| 6.3 Incident Tracking and Resolution | Type | TC-SA-24-06-018 |
| 6.3 Incident Tracking and Resolution | Status | TC-SA-24-06-019 |
| 6.3 Incident Tracking and Resolution | Resolution | TC-SA-24-06-020 |
| 6.3 Incident Tracking and Resolution | Incident count | TC-SA-24-06-021 |
| 6.3 Incident Tracking and Resolution | Incident duration | TC-SA-24-06-022 |
| 6.3 Incident Tracking and Resolution | Incident view | TC-SA-24-06-023 |
| 6.3 Incident Tracking and Resolution | Audit logging of the incident tracking and resolution | TC-SA-24-06-024 |
| 6.3 Incident Tracking and Resolution | Rule: the incident is the event/problem | TC-SA-24-06-017 |
| 6.3 Incident Tracking and Resolution | Rule: the type is the category/class | TC-SA-24-06-018 |
| 6.3 Incident Tracking and Resolution | Rule: the status is the state/phase | TC-SA-24-06-019 |
| 6.3 Incident Tracking and Resolution | Rule: the resolution is the fix/close | TC-SA-24-06-020 |
| 6.3 Incident Tracking and Resolution | Rule: the incidents are closed — tracking is managed | TC-SA-24-06-023 |
| 6.3 Incident Tracking and Resolution | Rule: audit-logged with incident, status, and timestamp | TC-SA-24-06-024 |

---

## 6.1 Error and Exception Monitoring

### TC-SA-24-06-001 — Errors and exceptions are monitored with error, type, and date
**Type:** Positive
**Covers:** 6.1 → Error; Rule: the error is the fault/failure
**Preconditions:** Super Admin logged in; errors and exceptions are being recorded by the system
**Steps:**
1. Open the Error and Exception Monitoring view
2. Observe the monitored error entries (error, type, date)
3. Verify each error reflects an actual fault in the system
**Expected Result:** The error of the system is monitored and displayed with the error, the type, and the date; the error is the fault/failure of the system
**Priority:** Critical

### TC-SA-24-06-002 — Error type is displayed as the correct category
**Type:** Positive
**Covers:** 6.1 → Type; Rule: the type is the category/class
**Preconditions:** Super Admin logged in; errors exist in multiple types (e.g., runtime, system)
**Steps:**
1. Open the Error and Exception Monitoring view
2. View the type of the errors
3. Verify each error is categorized with the correct type
**Expected Result:** The type of the error (e.g., runtime, system) is displayed as the correct category; the type is the class of the error and matches the actual fault
**Priority:** High

### TC-SA-24-06-003 — Exceptions are displayed with the correct type and date
**Type:** Positive
**Covers:** 6.1 → Exception; Rule: the exception is the event/anomaly
**Preconditions:** Super Admin logged in; exceptions have been recorded
**Steps:**
1. Open the Error and Exception Monitoring view
2. View the exceptions (exception, type, date)
3. Verify each exception reflects an actual anomaly event
**Expected Result:** The exception is displayed with the exception, the type, and the date; the exception is the event/anomaly and matches the actual recorded anomaly
**Priority:** High

### TC-SA-24-06-004 — Error status is shown as open or resolved
**Type:** Edge
**Covers:** 6.1 → Error status; Rule: the error status is the state/control
**Preconditions:** Super Admin logged in; errors exist in both open and resolved states
**Steps:**
1. View an unresolved error and verify its status
2. Resolve the error and verify its status changes to resolved
3. Verify the status always matches the actual state
**Expected Result:** The error status is displayed as open or resolved and always matches the actual state; an unresolved error is never shown as resolved; the status is the state/control
**Priority:** High

### TC-SA-24-06-005 — Error count by status is accurate
**Type:** Positive
**Covers:** 6.1 → Error count
**Preconditions:** Super Admin logged in; errors exist in both open and resolved states
**Steps:**
1. Open the Error and Exception Monitoring view
2. View the error count (count of errors by status)
3. Manually count open and resolved errors and compare
**Expected Result:** The error count shows the exact count of errors in each status; the count is the measure and matches the actual errors
**Priority:** High

### TC-SA-24-06-006 — Error period can be set to daily, weekly, or monthly
**Type:** Positive
**Covers:** 6.1 → Error period
**Preconditions:** Super Admin logged in; error history exists across multiple periods
**Steps:**
1. Open the Error and Exception Monitoring view
2. Set the error period to daily, then weekly, then monthly
3. Verify the displayed error data matches the selected period
**Expected Result:** The period of the errors (daily, weekly, monthly) can be set and the error data shown matches the selected period; the period is the scope of the watch
**Priority:** High

### TC-SA-24-06-007 — Error view shows errors, types, exceptions, and dates
**Type:** Positive
**Covers:** 6.1 → Error view; Rule: the errors are visible — monitoring is managed
**Preconditions:** Super Admin logged in; error data exists
**Steps:**
1. Open the error view
2. Verify the view lists the errors, the types, the exceptions, and the dates
3. Verify the errors are visible and the watch is complete
**Expected Result:** The error view displays the errors, the types, the exceptions, and the dates; the errors are visible and the monitoring is managed
**Priority:** Medium

### TC-SA-24-06-008 — Error and exception monitoring is audit-logged
**Type:** Positive
**Covers:** 6.1 → Audit logging of the error and exception monitoring; Rule: audit-logged with error, type, and timestamp
**Preconditions:** Super Admin logged in; audit log accessible
**Steps:**
1. Perform an error and exception monitoring action (view/resolve an error)
2. Open the audit log
3. Verify an entry exists with the error, the type, and the timestamp
**Expected Result:** The error and exception monitoring is audit-logged with the error, the type, and the timestamp
**Priority:** Critical

## 6.2 Alerting on Performance Degradation

### TC-SA-24-06-009 — Alert is sent when performance degrades, with alert, metric, threshold, and date
**Type:** Positive
**Covers:** 6.2 → Alert; Rule: the alert is the signal/notice
**Preconditions:** Super Admin logged in; a metric with a threshold is configured; a degradation can be induced
**Steps:**
1. Observe the system while the metric is within normal range
2. Induce a performance degradation that crosses the threshold
3. Verify an alert is sent with the alert, the metric, the threshold, and the date
**Expected Result:** The alert of the degradation (alert, metric, threshold, date) is sent when the performance degrades; the alert is the signal/notice and the degradation is flagged
**Priority:** Critical

### TC-SA-24-06-010 — A specific metric can be selected and inspected
**Type:** Positive
**Covers:** 6.2 → Metric; Rule: the metric is the measure/value
**Preconditions:** Super Admin logged in; multiple performance metrics exist
**Steps:**
1. Open the Alerting view
2. Select a specific metric
3. Verify the metric details (name, date) and its alert data are shown
**Expected Result:** The selected metric (the metric of the performance, with its name and date) is shown with its alert data; the metric is the measure/value being watched
**Priority:** High

### TC-SA-24-06-011 — Alert threshold can be set and fires exactly at the value
**Type:** Edge
**Covers:** 6.2 → Threshold; Rule: the threshold is the limit/trigger
**Preconditions:** Super Admin logged in; a metric with a configurable threshold exists
**Steps:**
1. Set the threshold of the alert (value, date) for a metric
2. Drive the metric just below the threshold and verify no alert is sent
3. Drive the metric exactly at/above the threshold and verify the alert fires
**Expected Result:** The threshold of the alert (value, date) can be set and fires exactly at the configured value; the metric below the threshold never alerts and at/above it always does; the threshold is the limit/trigger
**Priority:** High

### TC-SA-24-06-012 — Alert status is shown as sent, acknowledged, or resolved
**Type:** Positive
**Covers:** 6.2 → Alert status; Rule: the alert status is the state/control
**Preconditions:** Super Admin logged in; alerts exist in sent, acknowledged, and resolved states
**Steps:**
1. View a newly sent alert and verify its status
2. Acknowledge the alert and verify its status changes to acknowledged
3. Resolve the alert and verify its status changes to resolved
**Expected Result:** The alert status is displayed as sent, acknowledged, or resolved and always matches the actual state at every transition; the status is the state/control
**Priority:** High

### TC-SA-24-06-013 — Alert count by status is accurate
**Type:** Positive
**Covers:** 6.2 → Alert count
**Preconditions:** Super Admin logged in; alerts exist in multiple statuses
**Steps:**
1. Open the Alerting view
2. View the alert count (count of alerts by status)
3. Manually count alerts per status and compare
**Expected Result:** The alert count shows the exact count of alerts in each status; the count is the measure and matches the actual alerts
**Priority:** High

### TC-SA-24-06-014 — Alert period can be set to daily, weekly, or monthly
**Type:** Positive
**Covers:** 6.2 → Alert period
**Preconditions:** Super Admin logged in; alert history exists across multiple periods
**Steps:**
1. Open the Alerting view
2. Set the alert period to daily, then weekly, then monthly
3. Verify the displayed alert data matches the selected period
**Expected Result:** The period of the alerts (daily, weekly, monthly) can be set and the alert data shown matches the selected period; the period is the scope of the watch
**Priority:** High

### TC-SA-24-06-015 — Alert view shows alerts, metrics, thresholds, and dates
**Type:** Positive
**Covers:** 6.2 → Alert view; Rule: the degradation is flagged — alerting is managed
**Preconditions:** Super Admin logged in; alert data exists
**Steps:**
1. Open the alert view
2. Verify the view lists the alerts, the metrics, the thresholds, and the dates
3. Verify the degradation flagging is visible and the signal is complete
**Expected Result:** The alert view displays the alerts, the metrics, the thresholds, and the dates; the degradation is flagged and the alerting is managed
**Priority:** Medium

### TC-SA-24-06-016 — Performance degradation alerting is audit-logged
**Type:** Positive
**Covers:** 6.2 → Audit logging of the performance degradation alerting; Rule: audit-logged with alert, threshold, and timestamp
**Preconditions:** Super Admin logged in; audit log accessible
**Steps:**
1. Perform a performance degradation alerting action (set a threshold / acknowledge an alert)
2. Open the audit log
3. Verify an entry exists with the alert, the threshold, and the timestamp
**Expected Result:** The performance degradation alerting is audit-logged with the alert, the threshold, and the timestamp
**Priority:** Critical

## 6.3 Incident Tracking and Resolution

### TC-SA-24-06-017 — Incidents are tracked and resolved with incident, type, status, and date
**Type:** Positive
**Covers:** 6.3 → Incident; Rule: the incident is the event/problem
**Preconditions:** Super Admin logged in; incidents have been recorded in the system
**Steps:**
1. Open the Incident Tracking view
2. Observe the incident entries (incident, type, status, date)
3. Verify each incident reflects an actual problem in the system
**Expected Result:** The incident of the system is tracked and resolved with the incident, the type, the status, and the date; the incident is the event/problem of the system
**Priority:** Critical

### TC-SA-24-06-018 — Incident type is displayed as the correct category
**Type:** Positive
**Covers:** 6.3 → Type; Rule: the type is the category/class
**Preconditions:** Super Admin logged in; incidents exist in multiple types (e.g., outage, degradation)
**Steps:**
1. Open the Incident Tracking view
2. View the type of the incidents
3. Verify each incident is categorized with the correct type
**Expected Result:** The type of the incident (e.g., outage, degradation) is displayed as the correct category; the type is the class of the incident and matches the actual problem
**Priority:** High

### TC-SA-24-06-019 — Incident status transitions through open, in-progress, and resolved
**Type:** Edge
**Covers:** 6.3 → Status; Rule: the status is the state/phase
**Preconditions:** Super Admin logged in; an open incident exists
**Steps:**
1. View the open incident and verify its status
2. Start work on the incident and verify its status changes to in-progress
3. Complete the resolution and verify its status changes to resolved
**Expected Result:** The status of the incident (open, in-progress, resolved) transitions correctly at every step and always matches the actual phase; the status is the state/phase
**Priority:** High

### TC-SA-24-06-020 — Resolution is applied and closes the incident
**Type:** Positive
**Covers:** 6.3 → Resolution; Rule: the resolution is the fix/close
**Preconditions:** Super Admin logged in; an in-progress incident exists
**Steps:**
1. Open the Incident Tracking view
2. Apply the resolution (action, date) to the incident
3. Verify the incident is closed with the resolution recorded
**Expected Result:** The resolution of the incident (action, date) is applied and the incident is closed; the resolution is the fix/close and is recorded against the incident
**Priority:** High

### TC-SA-24-06-021 — Incident count by status is accurate
**Type:** Positive
**Covers:** 6.3 → Incident count
**Preconditions:** Super Admin logged in; incidents exist in multiple statuses
**Steps:**
1. Open the Incident Tracking view
2. View the incident count (count of incidents by status)
3. Manually count incidents per status and compare
**Expected Result:** The incident count shows the exact count of incidents in each status; the count is the measure and matches the actual incidents
**Priority:** High

### TC-SA-24-06-022 — Incident duration is displayed as the correct time
**Type:** Positive
**Covers:** 6.3 → Incident duration
**Preconditions:** Super Admin logged in; incidents exist with known start and end times
**Steps:**
1. Open the Incident Tracking view
2. View the duration of the incident (time)
3. Independently compute the duration from the start and end times and compare
**Expected Result:** The duration of the incident is displayed as the exact time; the duration is the time of the incident and matches the independently computed value
**Priority:** High

### TC-SA-24-06-023 — Incident view shows incidents, types, statuses, and dates
**Type:** Positive
**Covers:** 6.3 → Incident view; Rule: the incidents are closed — tracking is managed
**Preconditions:** Super Admin logged in; incident data exists
**Steps:**
1. Open the incident view
2. Verify the view lists the incidents, the types, the statuses, and the dates
3. Verify the incidents are visible and the watch is complete
**Expected Result:** The incident view displays the incidents, the types, the statuses, and the dates; the incidents are closed and the tracking is managed
**Priority:** Medium

### TC-SA-24-06-024 — Incident tracking and resolution is audit-logged
**Type:** Positive
**Covers:** 6.3 → Audit logging of the incident tracking and resolution; Rule: audit-logged with incident, status, and timestamp
**Preconditions:** Super Admin logged in; audit log accessible
**Steps:**
1. Perform an incident tracking and resolution action (apply a resolution)
2. Open the audit log
3. Verify an entry exists with the incident, the status, and the timestamp
**Expected Result:** The incident tracking and resolution is audit-logged with the incident, the status, and the timestamp
**Priority:** Critical