# 3. Feature Toggles — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: feature_toggles.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 |
|---------|--------------------|----------|
| 3.1 Enable or Disable Platform Features System-Wide | Feature toggle catalog: all toggleable features with their current state | TC-SA-04-03-001 |
| 3.1 Enable or Disable Platform Features System-Wide | System-wide enable/disable per feature | TC-SA-04-03-002 |
| 3.1 Enable or Disable Platform Features System-Wide | Immediate effect: a disabled feature is unavailable platform-wide on the next request | TC-SA-04-03-003 |
| 3.1 Enable or Disable Platform Features System-Wide | Dependency awareness: toggles that depend on other features show the dependency state | TC-SA-04-03-004 |
| 3.1 Enable or Disable Platform Features System-Wide | Change preview: what a toggle change affects (surfaces, user counts where relevant) | TC-SA-04-03-005 |
| 3.1 Enable or Disable Platform Features System-Wide | Change history of toggle states | TC-SA-04-03-006 |
| 3.1 Enable or Disable Platform Features System-Wide | Audit logging of toggle changes with the acting admin | TC-SA-04-03-007 |
| 3.1 Enable or Disable Platform Features System-Wide | Rule: a toggle change takes effect on the next request; there is no stale-availability window | TC-SA-04-03-003 |
| 3.1 Enable or Disable Platform Features System-Wide | Rule: dependencies are surfaced: enabling a feature whose dependency is disabled is flagged (not silently allowed into a broken state) | TC-SA-04-03-008 |
| 3.1 Enable or Disable Platform Features System-Wide | Rule: the change preview shows the impact before the change, so toggles are deliberate | TC-SA-04-03-005 |
| 3.1 Enable or Disable Platform Features System-Wide | Rule: toggling off a feature in active use ends its availability on the next request; in-progress work is handled per the feature's rules | TC-SA-04-03-009 |
| 3.1 Enable or Disable Platform Features System-Wide | Rule: the change history records every state change for reconstruction | TC-SA-04-03-006 |
| 3.1 Enable or Disable Platform Features System-Wide | Rule: toggle changes are audit-logged with the acting admin and timestamp | TC-SA-04-03-007 |
| 3.2 Control Availability of Optional Features | Optional feature catalog (live sessions, social learning, and similar secondary capabilities) | TC-SA-04-03-010 |
| 3.2 Control Availability of Optional Features | Enable/disable per optional feature | TC-SA-04-03-011 |
| 3.2 Control Availability of Optional Features | Availability coordination: the supporting configuration (permissions, content, operational readiness) checked before enablement | TC-SA-04-03-012 |
| 3.2 Control Availability of Optional Features | Launch checklist: the items that must be in place before an optional feature is turned on | TC-SA-04-03-013 |
| 3.2 Control Availability of Optional Features | Post-enable monitoring: health and usage signals after launch | TC-SA-04-03-014 |
| 3.2 Control Availability of Optional Features | Disable path with user communication for a pulled feature | TC-SA-04-03-015 |
| 3.2 Control Availability of Optional Features | Audit logging of optional-feature availability changes | TC-SA-04-03-016 |
| 3.2 Control Availability of Optional Features | Rule: optional features are gated by both the toggle and the user's permissions: a feature is available only where the toggle is on and the role permits it | TC-SA-04-03-017 |
| 3.2 Control Availability of Optional Features | Rule: the launch checklist must be complete before enablement; an incomplete checklist blocks the toggle with the missing items shown | TC-SA-04-03-013 |
| 3.2 Control Availability of Optional Features | Rule: disabling an optional feature in active use ends availability on the next request and triggers user communication | TC-SA-04-03-015 |
| 3.2 Control Availability of Optional Features | Rule: post-enable monitoring is expected: a launched feature is watched, not just switched on | TC-SA-04-03-014 |
| 3.2 Control Availability of Optional Features | Rule: the availability timeline is reconstructable from the change history | TC-SA-04-03-016 |
| 3.2 Control Availability of Optional Features | Rule: optional-feature availability changes are audit-logged with the acting admin and timestamp | TC-SA-04-03-016 |

## 3.1 Enable or Disable Platform Features System-Wide

### TC-SA-04-03-001 — The feature toggle catalog lists all toggleable features with their current state
**Type:** Positive
**Covers:** 3.1 → Feature toggle catalog: all toggleable features with their current state
**Preconditions:** The platform has 20 toggleable features; 15 are enabled, 5 disabled.
**Steps:**
1. Open the Feature Toggles catalog.
2. Verify all 20 features are listed with their current state (15 enabled, 5 disabled).
**Expected Result:** The catalog lists all toggleable features with their current state — complete and accurate.
**Priority:** High

### TC-SA-04-03-002 — A feature can be enabled or disabled system-wide
**Type:** Positive
**Covers:** 3.1 → System-wide enable/disable per feature
**Preconditions:** A feature is currently disabled system-wide.
**Steps:**
1. Enable the feature from the catalog.
2. Verify it is now enabled system-wide.
3. Disable it again and verify the state change.
**Expected Result:** The feature can be enabled and disabled system-wide — the state changes as configured.
**Priority:** Critical

### TC-SA-04-03-003 — A disabled feature is unavailable platform-wide on the next request; no stale-availability window
**Type:** Positive
**Covers:** 3.1 → Immediate effect: a disabled feature is unavailable platform-wide on the next request; Rule: a toggle change takes effect on the next request; there is no stale-availability window
**Preconditions:** A feature is enabled and in use; it is then disabled.
**Steps:**
1. Disable the feature.
2. Make the next request to the feature's surface.
3. Verify the feature is unavailable immediately.
**Expected Result:** The feature is unavailable on the next request — no stale-availability window; the disable is immediate.
**Priority:** Critical

### TC-SA-04-03-004 — Dependency awareness: toggles that depend on other features show the dependency state
**Type:** Positive
**Covers:** 3.1 → Dependency awareness: toggles that depend on other features show the dependency state
**Preconditions:** Feature B depends on Feature A; both are enabled.
**Steps:**
1. Open the dependency view for Feature B.
2. Verify it shows that Feature A (its dependency) is enabled.
3. Disable Feature A and verify Feature B's dependency state updates.
**Expected Result:** The dependency view shows Feature B's dependency (A) and its state — the dependency is surfaced.
**Priority:** High

### TC-SA-04-03-005 — Change preview shows what a toggle change affects (surfaces, user counts) before the change
**Type:** Positive
**Covers:** 3.1 → Change preview: what a toggle change affects (surfaces, user counts where relevant); Rule: the change preview shows the impact before the change, so toggles are deliberate
**Preconditions:** A feature is to be enabled; it appears on 3 surfaces and affects 5,000 users.
**Steps:**
1. Open the change preview for enabling the feature.
2. Verify the preview shows the surfaces (3) and the user impact (5,000).
**Expected Result:** The change preview shows the affected surfaces and user counts before the change — the toggle is deliberate.
**Priority:** High

### TC-SA-04-03-006 — Change history records every state change for reconstruction
**Type:** Positive
**Covers:** 3.1 → Change history of toggle states; Rule: the change history records every state change for reconstruction
**Preconditions:** A feature has been toggled on, off, and on again.
**Steps:**
1. Open the change history for the feature.
2. Verify each state change shows the previous and new state, the acting admin, and the timestamp.
**Expected Result:** The change history records all three state changes with previous/new state, acting admin, and timestamp — the feature's availability over time is reconstructable.
**Priority:** Medium

### TC-SA-04-03-007 — Toggle changes are audit-logged with the acting admin and timestamp
**Type:** Positive
**Covers:** 3.1 → Audit logging of toggle changes with the acting admin; Rule: toggle changes are audit-logged with the acting admin and timestamp
**Preconditions:** A toggle change has been made.
**Steps:**
1. Open the audit trail and filter by "toggle".
2. Verify the entry shows the feature, the change, the acting admin, and the timestamp.
**Expected Result:** The toggle change is audit-logged with the acting admin and timestamp.
**Priority:** Critical

### TC-SA-04-03-008 — Enabling a feature whose dependency is disabled is flagged, not silently allowed
**Type:** Negative
**Covers:** 3.1 → Rule: dependencies are surfaced: enabling a feature whose dependency is disabled is flagged (not silently allowed into a broken state)
**Preconditions:** Feature B depends on Feature A; Feature A is disabled.
**Steps:**
1. Attempt to enable Feature B.
2. Verify the disabled dependency (A) is flagged.
**Expected Result:** Enabling Feature B is flagged because its dependency (A) is disabled — it is not silently allowed into a broken state.
**Priority:** Critical

### TC-SA-04-03-009 — Toggling off a feature in active use ends availability on the next request; in-progress work is handled per the feature's rules
**Type:** Negative
**Covers:** 3.1 → Rule: toggling off a feature in active use ends its availability on the next request; in-progress work is handled per the feature's rules
**Preconditions:** A feature is in active use (a user has in-progress work); it is then disabled.
**Steps:**
1. Disable the feature while a user has in-progress work.
2. Verify the feature is unavailable on the next request.
3. Verify the in-progress work is handled per the feature's rules (not lost).
**Expected Result:** The feature is unavailable on the next request; the in-progress work is handled per the feature's rules — not silently lost.
**Priority:** High

## 3.2 Control Availability of Optional Features

### TC-SA-04-03-010 — The optional feature catalog lists live sessions, social learning, and similar secondary capabilities
**Type:** Positive
**Covers:** 3.2 → Optional feature catalog (live sessions, social learning, and similar secondary capabilities)
**Preconditions:** The platform has optional features: live sessions and social learning.
**Steps:**
1. Open the optional feature catalog.
2. Verify live sessions and social learning are listed.
**Expected Result:** The optional feature catalog lists the secondary capabilities (live sessions, social learning).
**Priority:** High

### TC-SA-04-03-011 — An optional feature can be enabled or disabled
**Type:** Positive
**Covers:** 3.2 → Enable/disable per optional feature
**Preconditions:** Live sessions is currently disabled.
**Steps:**
1. Enable live sessions from the catalog.
2. Verify it is now available to users whose roles permit it.
**Expected Result:** Live sessions is enabled and available to the users whose roles permit it.
**Priority:** Critical

### TC-SA-04-03-012 — Availability coordination: the supporting configuration (permissions, content, operational readiness) is checked before enablement
**Type:** Positive
**Covers:** 3.2 → Availability coordination: the supporting configuration (permissions, content, operational readiness) checked before enablement
**Preconditions:** Live sessions is to be enabled; the supporting permissions, scheduling surface, and operational readiness are being checked.
**Steps:**
1. Open the availability coordination view for live sessions.
2. Verify the supporting permissions, content, and operational readiness are checked.
**Expected Result:** The supporting configuration (permissions, content, operational readiness) is checked before enablement — coordination is enforced.
**Priority:** High

### TC-SA-04-03-013 — The launch checklist must be complete before enablement; an incomplete checklist blocks the toggle with the missing items shown
**Type:** Negative
**Covers:** 3.2 → Launch checklist: the items that must be in place before an optional feature is turned on; Rule: the launch checklist must be complete before enablement; an incomplete checklist blocks the toggle with the missing items shown
**Preconditions:** Live sessions has an incomplete launch checklist (the host permission is not yet assigned).
**Steps:**
1. Attempt to enable live sessions with the incomplete checklist.
2. Verify the toggle is blocked and the missing item (host permission) is shown.
**Expected Result:** The toggle is blocked because the checklist is incomplete; the missing item (host permission) is shown — enablement is not allowed.
**Priority:** Critical

### TC-SA-04-03-014 — Post-enable monitoring: health and usage signals are available after launch
**Type:** Positive
**Covers:** 3.2 → Post-enable monitoring: health and usage signals after launch; Rule: post-enable monitoring is expected: a launched feature is watched, not just switched on
**Preconditions:** Live sessions has been enabled and is in use.
**Steps:**
1. Open the post-enable monitoring view.
2. Verify the usage, session health, and error signals are available.
**Expected Result:** The post-enable monitoring shows usage, session health, and error signals — the launched feature is watched.
**Priority:** Medium

### TC-SA-04-03-015 — Disabling an optional feature in active use ends availability on the next request and triggers user communication
**Type:** Negative
**Covers:** 3.2 → Disable path with user communication for a pulled feature; Rule: disabling an optional feature in active use ends availability on the next request and triggers user communication
**Preconditions:** Social learning is in active use; it is to be pulled due to an issue.
**Steps:**
1. Disable social learning.
2. Verify it is unavailable on the next request.
3. Verify the user communication is triggered (feature temporarily unavailable, expected restoration).
**Expected Result:** Social learning is unavailable on the next request; the user communication is triggered with the expected restoration — the pull is communicated.
**Priority:** Critical

### TC-SA-04-03-016 — Optional-feature availability changes are audit-logged; the availability timeline is reconstructable
**Type:** Positive
**Covers:** 3.2 → Audit logging of optional-feature availability changes; Rule: the availability timeline is reconstructable from the change history; Rule: optional-feature availability changes are audit-logged with the acting admin and timestamp
**Preconditions:** Live sessions has been enabled and disabled over time.
**Steps:**
1. Open the audit trail and filter by "optional feature".
2. Verify each availability change shows the acting admin and timestamp.
3. Reconstruct the on/off timeline from the change history.
**Expected Result:** Each availability change is audit-logged with the acting admin and timestamp; the on/off timeline is reconstructable from the change history.
**Priority:** Critical

### TC-SA-04-03-017 — An optional feature is available only where the toggle is on and the role permits it
**Type:** Negative
**Covers:** 3.2 → Rule: optional features are gated by both the toggle and the user's permissions: a feature is available only where the toggle is on and the role permits it
**Preconditions:** Live sessions is enabled (toggle on); User A's role permits it; User B's role does not.
**Steps:**
1. Log in as User A and verify live sessions is available.
2. Log in as User B and verify live sessions is not available.
**Expected Result:** User A (role permits) sees live sessions; User B (role does not permit) does not — the feature is gated by both the toggle and the role.
**Priority:** Critical