# 1. Student Login — Test Cases

User Type: **Student**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: student_login.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 |
|---------|--------------------|----------|
| 1.1 Email and Password Login | Login screen with email and password fields, input validation (format check, trimming, case handling for email), and clear inline error messages | TC-ST-01-01-001 |
| 1.1 Email and Password Login | "Show/hide password" toggle and auto-fill support for password managers | TC-ST-01-01-002 |
| 1.1 Email and Password Login | "Forgot password" link on the login screen routing to the reset flow | TC-ST-01-01-003 |
| 1.1 Email and Password Login | "Remember me" checkbox for trusted devices | TC-ST-01-01-004 |
| 1.1 Email and Password Login | Rate limiting on login attempts per account and per IP to slow brute-force attacks | TC-ST-01-01-005 |
| 1.1 Email and Password Login | Progressive failure feedback: generic "invalid email or password" message (never reveals which field was wrong) | TC-ST-01-01-006 |
| 1.1 Email and Password Login | Pre-authentication checks applied in order: account status (active/suspended/deactivated), lockout state, IP allow/deny lists, location policy | TC-ST-01-01-007 |
| 1.1 Email and Password Login | Post-verification checks: 2FA challenge if enabled or mandatory | TC-ST-01-01-008 |
| 1.1 Email and Password Login | Session establishment on success: session record created, login event logged, Student redirected to the Student Dashboard | TC-ST-01-01-009 |
| 1.1 Email and Password Login | Login attempt logging: every attempt (success and failure) recorded with timestamp, IP, device, and failure reason | TC-ST-01-01-010 |
| 1.1 Email and Password Login | Mobile app parity: identical credential verification with device-bound session tokens | TC-ST-01-01-011 |
| 1.1 Email and Password Login | Audit logging of the student login | TC-ST-01-01-012 |
| 1.1 Email and Password Login | Rule: The error message never distinguishes between "email not found" and "wrong password" to prevent account enumeration. | TC-ST-01-01-001 |
| 1.1 Email and Password Login | Rule: Email addresses are matched case-insensitively; passwords are case-sensitive. | TC-ST-01-01-002 |
| 1.1 Email and Password Login | Rule: A suspended or deactivated account cannot log in at all; the message differs by state (suspended = temporary with appeal path; deactivated = permanent closure notice). | TC-ST-01-01-003 |
| 1.1 Email and Password Login | Rule: If the account is locked from repeated failures, the login screen shows the remaining lockout time and the support contact instead of accepting credentials. | TC-ST-01-01-004 |
| 1.1 Email and Password Login | Rule: If the source IP is on a deny list, the attempt is rejected before credential verification and logged as an IP-block event. | TC-ST-01-01-005 |
| 1.1 Email and Password Login | Rule: If 2FA is mandatory and the Student has not enrolled, login pauses at a guided enrollment step rather than failing. | TC-ST-01-01-006 |
| 1.1 Email and Password Login | Rule: Every login attempt — success, failure, block — is written to the login activity log with full context. | TC-ST-01-01-007 |
| 1.1 Email and Password Login | Rule: Sessions created via this method are subject to all session policies (timeouts, concurrency, remember-me). | TC-ST-01-01-008 |
| 1.1 Email and Password Login | Rule: The student login is audit-logged with the account, the outcome, and the timestamp. | TC-ST-01-01-009 |
| 1.2 OTP-Based Login Verification (Password + OTP) | OTP delivery channel selection: SMS to registered phone and/or email, with fallback channel if the primary fails | TC-ST-01-01-013 |
| 1.2 OTP-Based Login Verification (Password + OTP) | OTP generation: 6-digit numeric code, cryptographically random, single-use | TC-ST-01-01-014 |
| 1.2 OTP-Based Login Verification (Password + OTP) | OTP validity window (e.g., 5 minutes) with countdown shown on the entry screen | TC-ST-01-01-015 |
| 1.2 OTP-Based Login Verification (Password + OTP) | OTP entry screen with auto-advance digit fields and paste support | TC-ST-01-01-016 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Resend with cooldown (e.g., 60 seconds) and a maximum resend count per login attempt | TC-ST-01-01-017 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Attempt limit: a fixed number of wrong OTP entries (e.g., 5) invalidates the current OTP and requires a fresh one | TC-ST-01-01-018 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Login completion: on valid OTP, session established and Student redirected to the Student Dashboard | TC-ST-01-01-019 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Failure handling: expired OTP, wrong OTP, and delivery failure each produce distinct, actionable messages | TC-ST-01-01-020 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Delivery failure fallback: if SMS fails, offer email delivery or a support-assisted path | TC-ST-01-01-021 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Full logging of each OTP issuance, verification, failure, and expiry | TC-ST-01-01-022 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Audit logging of the OTP-based login verification | TC-ST-01-01-023 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: The OTP is single-use: a verified code cannot be reused, even within its validity window. | TC-ST-01-01-013 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: The OTP expires at the end of its validity window; an expired code produces an "expired" message with a resend option, not a generic error. | TC-ST-01-01-014 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: Wrong-OTP attempts are counted per issued code; exceeding the limit invalidates that code and requires a new issuance. | TC-ST-01-01-015 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: Resends are rate-limited (cooldown plus a maximum per login session) to prevent SMS abuse. | TC-ST-01-01-016 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: If the registered phone is unreachable (no network, number changed), the Student can switch to email delivery if registered, or use the support-assisted recovery path. | TC-ST-01-01-017 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: OTPs are never logged in full; only the event (issued/verified/failed/expired) and channel are recorded. | TC-ST-01-01-018 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: OTP delivery latency is out of the platform's control; the UI always shows the expiry countdown so the Student knows when to resend. | TC-ST-01-01-019 |
| 1.2 OTP-Based Login Verification (Password + OTP) | Rule: The OTP-based login verification is audit-logged with the account, the channel, and the timestamp. | TC-ST-01-01-020 |
| 1.3 Social Login (Google, Facebook) | First-login account creation: social profile (name, email, profile picture) used to create the platform account, with required fields (e.g., phone, grade) prompted afterwards | TC-ST-01-01-024 |
| 1.3 Social Login (Google, Facebook) | Account matching: if the social provider's email matches an existing platform account, offer to link rather than create a duplicate | TC-ST-01-01-025 |
| 1.3 Social Login (Google, Facebook) | Account linking: a Student with an existing email/password account can add a social provider from profile settings (with password verification) | TC-ST-01-01-026 |
| 1.3 Social Login (Google, Facebook) | Unlinking: remove a social provider from the account, blocked if it would leave the account with no authentication method | TC-ST-01-01-027 |
| 1.3 Social Login (Google, Facebook) | Consent capture: the social provider's data usage is covered by the platform privacy policy at first login | TC-ST-01-01-028 |
| 1.3 Social Login (Google, Facebook) | Session behavior identical to password login (2FA policy, session policies, logging all apply) | TC-ST-01-01-029 |
| 1.3 Social Login (Google, Facebook) | Provider outage handling: if the provider is unreachable, the Student falls back to email/password login with a notice | TC-ST-01-01-030 |
| 1.3 Social Login (Google, Facebook) | Social login usage and failure visibility per provider | TC-ST-01-01-031 |
| 1.3 Social Login (Google, Facebook) | Audit logging of the social login | TC-ST-01-01-032 |
| 1.3 Social Login (Google, Facebook) | Rule: A social login can never be the only authentication method; the account must retain at least one working method (password or another provider). | TC-ST-01-01-024 |
| 1.3 Social Login (Google, Facebook) | Rule: Linking a social provider to an account requires verifying the account's existing password first (prevents an attacker from linking their own social identity to a victim account). | TC-ST-01-01-025 |
| 1.3 Social Login (Google, Facebook) | Rule: Unlinking is blocked if the account has no other working authentication method. | TC-ST-01-01-026 |
| 1.3 Social Login (Google, Facebook) | Rule: If the provider's email is already used by another platform account, the system offers linking/merge review rather than silently creating a duplicate. | TC-ST-01-01-027 |
| 1.3 Social Login (Google, Facebook) | Rule: Social provider outages degrade gracefully: the button is hidden or shows an unavailable notice; email/password login remains available. | TC-ST-01-01-028 |
| 1.3 Social Login (Google, Facebook) | Rule: All social logins are logged with provider, outcome, and account, and are subject to the same lockout and IP policies as password logins. | TC-ST-01-01-029 |
| 1.3 Social Login (Google, Facebook) | Rule: Data received from the provider (name, email, picture) is stored per the privacy policy and is visible in the Student's profile data export. | TC-ST-01-01-030 |
| 1.3 Social Login (Google, Facebook) | Rule: The social login is audit-logged with the provider, the account, and the timestamp. | TC-ST-01-01-031 |
| 1.4 Two-Factor Authentication | Enrollment: choose a second factor (authenticator app via QR code, or SMS to registered phone) | TC-ST-01-01-033 |
| 1.4 Two-Factor Authentication | Authenticator app setup: QR code scan, confirmation code entry to verify the app | TC-ST-01-01-034 |
| 1.4 Two-Factor Authentication | SMS setup: send a test code to the registered phone and verify it | TC-ST-01-01-035 |
| 1.4 Two-Factor Authentication | Backup codes: generate a set of single-use backup codes for when the primary factor is unavailable | TC-ST-01-01-036 |
| 1.4 Two-Factor Authentication | Login challenge: after password verification, present the second-factor entry screen | TC-ST-01-01-037 |
| 1.4 Two-Factor Authentication | Change factor: switch from one factor type to another (requires verifying the current factor first) | TC-ST-01-01-038 |
| 1.4 Two-Factor Authentication | Remove factor: disable 2FA (requires password + current factor verification), subject to policy | TC-ST-01-01-039 |
| 1.4 Two-Factor Authentication | Recovery: use a backup code or the support-assisted path when the primary factor is lost | TC-ST-01-01-040 |
| 1.4 Two-Factor Authentication | Status visibility: the Student can see whether 2FA is on and which factor type is enrolled | TC-ST-01-01-041 |
| 1.4 Two-Factor Authentication | Audit logging of the two-factor authentication | TC-ST-01-01-042 |
| 1.4 Two-Factor Authentication | Rule: Enrolling or changing a factor requires verifying the current factor (or password for the first enrollment). | TC-ST-01-01-033 |
| 1.4 Two-Factor Authentication | Rule: Removing 2FA requires both the password and the current factor, and is subject to the platform's security policy (some accounts may have mandatory 2FA that cannot be removed). | TC-ST-01-01-034 |
| 1.4 Two-Factor Authentication | Rule: Backup codes are single-use; each code can be used once, and the remaining count is shown. | TC-ST-01-01-035 |
| 1.4 Two-Factor Authentication | Rule: If the primary factor is lost and no backup codes remain, the Student must use the support-assisted recovery path. | TC-ST-01-01-036 |
| 1.4 Two-Factor Authentication | Rule: The second-factor challenge is presented only after the password is verified; a wrong password never triggers an OTP. | TC-ST-01-01-037 |
| 1.4 Two-Factor Authentication | Rule: 2FA challenges are rate-limited and logged (issued/verified/failed/expired) without storing the code itself. | TC-ST-01-01-038 |
| 1.4 Two-Factor Authentication | Rule: The two-factor authentication enrollment, change, and removal are audit-logged with the account, the factor type, and the timestamp. | TC-ST-01-01-039 |

## 1.1 Email and Password Login

### TC-ST-01-01-001 — Login screen with email and password fields, input validation (format check, trimming, case handling for email), and clear inline error messages
**Type:** Edge
**Covers:** 1.1 → Login screen with email and password fields, input validation (format check, trimming, case handling for email), and clear inline error messages; Rule: The error message never distinguishes between "email not found" and "wrong password" to prevent account enumeration.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Login screen with email and password fields.
2. Observe the result and verify the full behavior: Login screen with email and password fields, input validation (format check, trimming, case handling for email), and clear inline error messages.
**Expected Result:** Login screen with email and password fields, input validation (format check, trimming, case handling for email), and clear inline error messages — delivered exactly as documented.
**Priority:** Critical

### TC-ST-01-01-002 — "Show/hide password" toggle and auto-fill support for password managers
**Type:** Positive
**Covers:** 1.1 → "Show/hide password" toggle and auto-fill support for password managers; Rule: Email addresses are matched case-insensitively; passwords are case-sensitive.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: "Show/hide password" toggle and auto-fill support for password managers.
2. Observe the result and verify the full behavior: "Show/hide password" toggle and auto-fill support for password managers.
**Expected Result:** "Show/hide password" toggle and auto-fill support for password managers — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-003 — "Forgot password" link on the login screen routing to the reset flow
**Type:** Positive
**Covers:** 1.1 → "Forgot password" link on the login screen routing to the reset flow; Rule: A suspended or deactivated account cannot log in at all; the message differs by state (suspended = temporary with appeal path; deactivated = permanent closure notice).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: "Forgot password" link on the login screen routing to the reset flow.
2. Observe the result and verify the full behavior: "Forgot password" link on the login screen routing to the reset flow.
**Expected Result:** "Forgot password" link on the login screen routing to the reset flow — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-004 — "Remember me" checkbox for trusted devices
**Type:** Positive
**Covers:** 1.1 → "Remember me" checkbox for trusted devices; Rule: If the account is locked from repeated failures, the login screen shows the remaining lockout time and the support contact instead of accepting credentials.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: "Remember me" checkbox for trusted devices.
2. Observe the result and verify the full behavior: "Remember me" checkbox for trusted devices.
**Expected Result:** "Remember me" checkbox for trusted devices — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-005 — Rate limiting on login attempts per account and per IP to slow brute-force attacks
**Type:** Edge
**Covers:** 1.1 → Rate limiting on login attempts per account and per IP to slow brute-force attacks; Rule: If the source IP is on a deny list, the attempt is rejected before credential verification and logged as an IP-block event.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Rate limiting on login attempts per account and per IP to slow brute-force attacks.
2. Observe the result and verify the full behavior: Rate limiting on login attempts per account and per IP to slow brute-force attacks.
**Expected Result:** Rate limiting on login attempts per account and per IP to slow brute-force attacks — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-006 — Progressive failure feedback: generic "invalid email or password" message (never reveals which field was wrong)
**Type:** Edge
**Covers:** 1.1 → Progressive failure feedback: generic "invalid email or password" message (never reveals which field was wrong); Rule: If 2FA is mandatory and the Student has not enrolled, login pauses at a guided enrollment step rather than failing.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Progressive failure feedback: generic "invalid email or password" message (never reveals which field was wrong).
2. Observe the result and verify the full behavior: Progressive failure feedback: generic "invalid email or password" message (never reveals which field was wrong).
**Expected Result:** Progressive failure feedback: generic "invalid email or password" message (never reveals which field was wrong) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-007 — Pre-authentication checks applied in order: account status (active/suspended/deactivated), lockout state, IP allow/deny lists, location policy
**Type:** Edge
**Covers:** 1.1 → Pre-authentication checks applied in order: account status (active/suspended/deactivated), lockout state, IP allow/deny lists, location policy; Rule: Every login attempt — success, failure, block — is written to the login activity log with full context.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Pre-authentication checks applied in order: account status (active/suspended/deactivated).
2. Observe the result and verify the full behavior: Pre-authentication checks applied in order: account status (active/suspended/deactivated), lockout state, IP allow/deny lists, location policy.
**Expected Result:** Pre-authentication checks applied in order: account status (active/suspended/deactivated), lockout state, IP allow/deny lists, location policy — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-008 — Post-verification checks: 2FA challenge if enabled or mandatory
**Type:** Positive
**Covers:** 1.1 → Post-verification checks: 2FA challenge if enabled or mandatory; Rule: Sessions created via this method are subject to all session policies (timeouts, concurrency, remember-me).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Post-verification checks: 2FA challenge if enabled or mandatory.
2. Observe the result and verify the full behavior: Post-verification checks: 2FA challenge if enabled or mandatory.
**Expected Result:** Post-verification checks: 2FA challenge if enabled or mandatory — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-009 — Session establishment on success: session record created, login event logged, Student redirected to the Student Dashboard
**Type:** Positive
**Covers:** 1.1 → Session establishment on success: session record created, login event logged, Student redirected to the Student Dashboard; Rule: The student login is audit-logged with the account, the outcome, and the timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Session establishment on success: session record created.
2. Observe the result and verify the full behavior: Session establishment on success: session record created, login event logged, Student redirected to the Student Dashboard.
**Expected Result:** Session establishment on success: session record created, login event logged, Student redirected to the Student Dashboard — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-010 — Login attempt logging: every attempt (success and failure) recorded with timestamp, IP, device, and failure reason
**Type:** Positive
**Covers:** 1.1 → Login attempt logging: every attempt (success and failure) recorded with timestamp, IP, device, and failure reason
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Login attempt logging: every attempt (success and failure) recorded with timestamp.
2. Observe the result and verify the full behavior: Login attempt logging: every attempt (success and failure) recorded with timestamp, IP, device, and failure reason.
**Expected Result:** Login attempt logging: every attempt (success and failure) recorded with timestamp, IP, device, and failure reason — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-011 — Mobile app parity: identical credential verification with device-bound session tokens
**Type:** Positive
**Covers:** 1.1 → Mobile app parity: identical credential verification with device-bound session tokens
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Mobile app parity: identical credential verification with device-bound session tokens.
2. Observe the result and verify the full behavior: Mobile app parity: identical credential verification with device-bound session tokens.
**Expected Result:** Mobile app parity: identical credential verification with device-bound session tokens — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-012 — Audit logging of the student login
**Type:** Positive
**Covers:** 1.1 → Audit logging of the student login
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, perform the action associated with: Audit logging of the student login.
2. Open the relevant activity / audit log and verify the event is recorded with the account, the action, and the timestamp.
**Expected Result:** The action is audit-logged — the account, the action, and the timestamp are recorded.
**Priority:** Critical

## 1.2 OTP-Based Login Verification (Password + OTP)

### TC-ST-01-01-013 — OTP delivery channel selection: SMS to registered phone and/or email, with fallback channel if the primary fails
**Type:** Positive
**Covers:** 1.2 → OTP delivery channel selection: SMS to registered phone and/or email, with fallback channel if the primary fails; Rule: The OTP is single-use: a verified code cannot be reused, even within its validity window.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: OTP delivery channel selection: SMS to registered phone and/or email.
2. Observe the result and verify the full behavior: OTP delivery channel selection: SMS to registered phone and/or email, with fallback channel if the primary fails.
**Expected Result:** OTP delivery channel selection: SMS to registered phone and/or email, with fallback channel if the primary fails — delivered exactly as documented.
**Priority:** Critical

### TC-ST-01-01-014 — OTP generation: 6-digit numeric code, cryptographically random, single-use
**Type:** Edge
**Covers:** 1.2 → OTP generation: 6-digit numeric code, cryptographically random, single-use; Rule: The OTP expires at the end of its validity window; an expired code produces an "expired" message with a resend option, not a generic error.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: OTP generation: 6-digit numeric code.
2. Observe the result and verify the full behavior: OTP generation: 6-digit numeric code, cryptographically random, single-use.
**Expected Result:** OTP generation: 6-digit numeric code, cryptographically random, single-use — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-015 — OTP validity window (e.g., 5 minutes) with countdown shown on the entry screen
**Type:** Positive
**Covers:** 1.2 → OTP validity window (e.g., 5 minutes) with countdown shown on the entry screen; Rule: Wrong-OTP attempts are counted per issued code; exceeding the limit invalidates that code and requires a new issuance.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: OTP validity window (e.g..
2. Observe the result and verify the full behavior: OTP validity window (e.g., 5 minutes) with countdown shown on the entry screen.
**Expected Result:** OTP validity window (e.g., 5 minutes) with countdown shown on the entry screen — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-016 — OTP entry screen with auto-advance digit fields and paste support
**Type:** Positive
**Covers:** 1.2 → OTP entry screen with auto-advance digit fields and paste support; Rule: Resends are rate-limited (cooldown plus a maximum per login session) to prevent SMS abuse.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: OTP entry screen with auto-advance digit fields and paste support.
2. Observe the result and verify the full behavior: OTP entry screen with auto-advance digit fields and paste support.
**Expected Result:** OTP entry screen with auto-advance digit fields and paste support — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-017 — Resend with cooldown (e.g., 60 seconds) and a maximum resend count per login attempt
**Type:** Edge
**Covers:** 1.2 → Resend with cooldown (e.g., 60 seconds) and a maximum resend count per login attempt; Rule: If the registered phone is unreachable (no network, number changed), the Student can switch to email delivery if registered, or use the support-assisted recovery path.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Resend with cooldown (e.g..
2. Observe the result and verify the full behavior: Resend with cooldown (e.g., 60 seconds) and a maximum resend count per login attempt.
**Expected Result:** Resend with cooldown (e.g., 60 seconds) and a maximum resend count per login attempt — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-018 — Attempt limit: a fixed number of wrong OTP entries (e.g., 5) invalidates the current OTP and requires a fresh one
**Type:** Edge
**Covers:** 1.2 → Attempt limit: a fixed number of wrong OTP entries (e.g., 5) invalidates the current OTP and requires a fresh one; Rule: OTPs are never logged in full; only the event (issued/verified/failed/expired) and channel are recorded.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Attempt limit: a fixed number of wrong OTP entries (e.g..
2. Observe the result and verify the full behavior: Attempt limit: a fixed number of wrong OTP entries (e.g., 5) invalidates the current OTP and requires a fresh one.
**Expected Result:** Attempt limit: a fixed number of wrong OTP entries (e.g., 5) invalidates the current OTP and requires a fresh one — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-019 — Login completion: on valid OTP, session established and Student redirected to the Student Dashboard
**Type:** Positive
**Covers:** 1.2 → Login completion: on valid OTP, session established and Student redirected to the Student Dashboard; Rule: OTP delivery latency is out of the platform's control; the UI always shows the expiry countdown so the Student knows when to resend.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Login completion: on valid OTP.
2. Observe the result and verify the full behavior: Login completion: on valid OTP, session established and Student redirected to the Student Dashboard.
**Expected Result:** Login completion: on valid OTP, session established and Student redirected to the Student Dashboard — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-020 — Failure handling: expired OTP, wrong OTP, and delivery failure each produce distinct, actionable messages
**Type:** Edge
**Covers:** 1.2 → Failure handling: expired OTP, wrong OTP, and delivery failure each produce distinct, actionable messages; Rule: The OTP-based login verification is audit-logged with the account, the channel, and the timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Failure handling: expired OTP.
2. Observe the result and verify the full behavior: Failure handling: expired OTP, wrong OTP, and delivery failure each produce distinct, actionable messages.
**Expected Result:** Failure handling: expired OTP, wrong OTP, and delivery failure each produce distinct, actionable messages — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-021 — Delivery failure fallback: if SMS fails, offer email delivery or a support-assisted path
**Type:** Positive
**Covers:** 1.2 → Delivery failure fallback: if SMS fails, offer email delivery or a support-assisted path
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Delivery failure fallback: if SMS fails.
2. Observe the result and verify the full behavior: Delivery failure fallback: if SMS fails, offer email delivery or a support-assisted path.
**Expected Result:** Delivery failure fallback: if SMS fails, offer email delivery or a support-assisted path — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-022 — Full logging of each OTP issuance, verification, failure, and expiry
**Type:** Edge
**Covers:** 1.2 → Full logging of each OTP issuance, verification, failure, and expiry
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Full logging of each OTP issuance.
2. Observe the result and verify the full behavior: Full logging of each OTP issuance, verification, failure, and expiry.
**Expected Result:** Full logging of each OTP issuance, verification, failure, and expiry — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-023 — Audit logging of the OTP-based login verification
**Type:** Positive
**Covers:** 1.2 → Audit logging of the OTP-based login verification
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, perform the action associated with: Audit logging of the OTP-based login verification.
2. Open the relevant activity / audit log and verify the event is recorded with the account, the action, and the timestamp.
**Expected Result:** The action is audit-logged — the account, the action, and the timestamp are recorded.
**Priority:** Critical

## 1.3 Social Login (Google, Facebook)

### TC-ST-01-01-024 — First-login account creation: social profile (name, email, profile picture) used to create the platform account, with required fields (e.g., phone, grade) prompted afterwards
**Type:** Positive
**Covers:** 1.3 → First-login account creation: social profile (name, email, profile picture) used to create the platform account, with required fields (e.g., phone, grade) prompted afterwards; Rule: A social login can never be the only authentication method; the account must retain at least one working method (password or another provider).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: First-login account creation: social profile (name.
2. Observe the result and verify the full behavior: First-login account creation: social profile (name, email, profile picture) used to create the platform account, with required fields (e.g., phone, grade) prompted afterwards.
**Expected Result:** First-login account creation: social profile (name, email, profile picture) used to create the platform account, with required fields (e.g., phone, grade) prompted afterwards — delivered exactly as documented.
**Priority:** Critical

### TC-ST-01-01-025 — Account matching: if the social provider's email matches an existing platform account, offer to link rather than create a duplicate
**Type:** Edge
**Covers:** 1.3 → Account matching: if the social provider's email matches an existing platform account, offer to link rather than create a duplicate; Rule: Linking a social provider to an account requires verifying the account's existing password first (prevents an attacker from linking their own social identity to a victim account).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Account matching: if the social provider's email matches an existing platform account.
2. Observe the result and verify the full behavior: Account matching: if the social provider's email matches an existing platform account, offer to link rather than create a duplicate.
**Expected Result:** Account matching: if the social provider's email matches an existing platform account, offer to link rather than create a duplicate — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-026 — Account linking: a Student with an existing email/password account can add a social provider from profile settings (with password verification)
**Type:** Positive
**Covers:** 1.3 → Account linking: a Student with an existing email/password account can add a social provider from profile settings (with password verification); Rule: Unlinking is blocked if the account has no other working authentication method.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Account linking: a Student with an existing email/password account can add a social provider from profile settings (with password verification).
2. Observe the result and verify the full behavior: Account linking: a Student with an existing email/password account can add a social provider from profile settings (with password verification).
**Expected Result:** Account linking: a Student with an existing email/password account can add a social provider from profile settings (with password verification) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-027 — Unlinking: remove a social provider from the account, blocked if it would leave the account with no authentication method
**Type:** Edge
**Covers:** 1.3 → Unlinking: remove a social provider from the account, blocked if it would leave the account with no authentication method; Rule: If the provider's email is already used by another platform account, the system offers linking/merge review rather than silently creating a duplicate.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Unlinking: remove a social provider from the account.
2. Observe the result and verify the full behavior: Unlinking: remove a social provider from the account, blocked if it would leave the account with no authentication method.
**Expected Result:** Unlinking: remove a social provider from the account, blocked if it would leave the account with no authentication method — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-028 — Consent capture: the social provider's data usage is covered by the platform privacy policy at first login
**Type:** Positive
**Covers:** 1.3 → Consent capture: the social provider's data usage is covered by the platform privacy policy at first login; Rule: Social provider outages degrade gracefully: the button is hidden or shows an unavailable notice; email/password login remains available.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Consent capture: the social provider's data usage is covered by the platform privacy policy at first login.
2. Observe the result and verify the full behavior: Consent capture: the social provider's data usage is covered by the platform privacy policy at first login.
**Expected Result:** Consent capture: the social provider's data usage is covered by the platform privacy policy at first login — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-029 — Session behavior identical to password login (2FA policy, session policies, logging all apply)
**Type:** Positive
**Covers:** 1.3 → Session behavior identical to password login (2FA policy, session policies, logging all apply); Rule: All social logins are logged with provider, outcome, and account, and are subject to the same lockout and IP policies as password logins.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Session behavior identical to password login (2FA policy.
2. Observe the result and verify the full behavior: Session behavior identical to password login (2FA policy, session policies, logging all apply).
**Expected Result:** Session behavior identical to password login (2FA policy, session policies, logging all apply) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-030 — Provider outage handling: if the provider is unreachable, the Student falls back to email/password login with a notice
**Type:** Positive
**Covers:** 1.3 → Provider outage handling: if the provider is unreachable, the Student falls back to email/password login with a notice; Rule: Data received from the provider (name, email, picture) is stored per the privacy policy and is visible in the Student's profile data export.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Provider outage handling: if the provider is unreachable.
2. Observe the result and verify the full behavior: Provider outage handling: if the provider is unreachable, the Student falls back to email/password login with a notice.
**Expected Result:** Provider outage handling: if the provider is unreachable, the Student falls back to email/password login with a notice — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-031 — Social login usage and failure visibility per provider
**Type:** Positive
**Covers:** 1.3 → Social login usage and failure visibility per provider; Rule: The social login is audit-logged with the provider, the account, and the timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Social login usage and failure visibility per provider.
2. Observe the result and verify the full behavior: Social login usage and failure visibility per provider.
**Expected Result:** Social login usage and failure visibility per provider — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-032 — Audit logging of the social login
**Type:** Positive
**Covers:** 1.3 → Audit logging of the social login
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, perform the action associated with: Audit logging of the social login.
2. Open the relevant activity / audit log and verify the event is recorded with the account, the action, and the timestamp.
**Expected Result:** The action is audit-logged — the account, the action, and the timestamp are recorded.
**Priority:** Critical

## 1.4 Two-Factor Authentication

### TC-ST-01-01-033 — Enrollment: choose a second factor (authenticator app via QR code, or SMS to registered phone)
**Type:** Positive
**Covers:** 1.4 → Enrollment: choose a second factor (authenticator app via QR code, or SMS to registered phone); Rule: Enrolling or changing a factor requires verifying the current factor (or password for the first enrollment).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Enrollment: choose a second factor (authenticator app via QR code.
2. Observe the result and verify the full behavior: Enrollment: choose a second factor (authenticator app via QR code, or SMS to registered phone).
**Expected Result:** Enrollment: choose a second factor (authenticator app via QR code, or SMS to registered phone) — delivered exactly as documented.
**Priority:** Critical

### TC-ST-01-01-034 — Authenticator app setup: QR code scan, confirmation code entry to verify the app
**Type:** Positive
**Covers:** 1.4 → Authenticator app setup: QR code scan, confirmation code entry to verify the app; Rule: Removing 2FA requires both the password and the current factor, and is subject to the platform's security policy (some accounts may have mandatory 2FA that cannot be removed).
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Authenticator app setup: QR code scan.
2. Observe the result and verify the full behavior: Authenticator app setup: QR code scan, confirmation code entry to verify the app.
**Expected Result:** Authenticator app setup: QR code scan, confirmation code entry to verify the app — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-035 — SMS setup: send a test code to the registered phone and verify it
**Type:** Positive
**Covers:** 1.4 → SMS setup: send a test code to the registered phone and verify it; Rule: Backup codes are single-use; each code can be used once, and the remaining count is shown.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: SMS setup: send a test code to the registered phone and verify it.
2. Observe the result and verify the full behavior: SMS setup: send a test code to the registered phone and verify it.
**Expected Result:** SMS setup: send a test code to the registered phone and verify it — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-036 — Backup codes: generate a set of single-use backup codes for when the primary factor is unavailable
**Type:** Edge
**Covers:** 1.4 → Backup codes: generate a set of single-use backup codes for when the primary factor is unavailable; Rule: If the primary factor is lost and no backup codes remain, the Student must use the support-assisted recovery path.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Backup codes: generate a set of single-use backup codes for when the primary factor is unavailable.
2. Observe the result and verify the full behavior: Backup codes: generate a set of single-use backup codes for when the primary factor is unavailable.
**Expected Result:** Backup codes: generate a set of single-use backup codes for when the primary factor is unavailable — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-037 — Login challenge: after password verification, present the second-factor entry screen
**Type:** Positive
**Covers:** 1.4 → Login challenge: after password verification, present the second-factor entry screen; Rule: The second-factor challenge is presented only after the password is verified; a wrong password never triggers an OTP.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Login challenge: after password verification.
2. Observe the result and verify the full behavior: Login challenge: after password verification, present the second-factor entry screen.
**Expected Result:** Login challenge: after password verification, present the second-factor entry screen — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-038 — Change factor: switch from one factor type to another (requires verifying the current factor first)
**Type:** Positive
**Covers:** 1.4 → Change factor: switch from one factor type to another (requires verifying the current factor first); Rule: 2FA challenges are rate-limited and logged (issued/verified/failed/expired) without storing the code itself.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Change factor: switch from one factor type to another (requires verifying the current factor first).
2. Observe the result and verify the full behavior: Change factor: switch from one factor type to another (requires verifying the current factor first).
**Expected Result:** Change factor: switch from one factor type to another (requires verifying the current factor first) — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-039 — Remove factor: disable 2FA (requires password + current factor verification), subject to policy
**Type:** Positive
**Covers:** 1.4 → Remove factor: disable 2FA (requires password + current factor verification), subject to policy; Rule: The two-factor authentication enrollment, change, and removal are audit-logged with the account, the factor type, and the timestamp.
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Remove factor: disable 2FA (requires password + current factor verification).
2. Observe the result and verify the full behavior: Remove factor: disable 2FA (requires password + current factor verification), subject to policy.
**Expected Result:** Remove factor: disable 2FA (requires password + current factor verification), subject to policy — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-040 — Recovery: use a backup code or the support-assisted path when the primary factor is lost
**Type:** Positive
**Covers:** 1.4 → Recovery: use a backup code or the support-assisted path when the primary factor is lost
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Recovery: use a backup code or the support-assisted path when the primary factor is lost.
2. Observe the result and verify the full behavior: Recovery: use a backup code or the support-assisted path when the primary factor is lost.
**Expected Result:** Recovery: use a backup code or the support-assisted path when the primary factor is lost — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-041 — Status visibility: the Student can see whether 2FA is on and which factor type is enrolled
**Type:** Positive
**Covers:** 1.4 → Status visibility: the Student can see whether 2FA is on and which factor type is enrolled
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, set up the precondition and perform: Status visibility: the Student can see whether 2FA is on and which factor type is enrolled.
2. Observe the result and verify the full behavior: Status visibility: the Student can see whether 2FA is on and which factor type is enrolled.
**Expected Result:** Status visibility: the Student can see whether 2FA is on and which factor type is enrolled — delivered exactly as documented.
**Priority:** High

### TC-ST-01-01-042 — Audit logging of the two-factor authentication
**Type:** Positive
**Covers:** 1.4 → Audit logging of the two-factor authentication
**Preconditions:** A Student account is active and the Student is in the state required for this behavior.
**Steps:**
1. As a Student, perform the action associated with: Audit logging of the two-factor authentication.
2. Open the relevant activity / audit log and verify the event is recorded with the account, the action, and the timestamp.
**Expected Result:** The action is audit-logged — the account, the action, and the timestamp are recorded.
**Priority:** Critical