How to Write Test Cases for a Login Page (with Examples)

Last updated: June 27, 2026 · 7 min read

A login page is the #1 test case exercise in QA interviews. This guide gives you 30+ production-grade test cases covering UI, functional, validation, security, and accessibility. Pair it with our Manual Testing Complete Guide and the Software Testing Interview Questions master list.

Before writing test cases, identify the components:

• Email / Username field
• Password field
• "Show password" toggle
• "Remember me" checkbox
• "Forgot password?" link
• "Sign in" button
• "Sign up" link
• Error message area
• Social login buttons (Google, Apple, etc.)
• CAPTCHA (when applicable)

TC_UI_001 — Email field is visible and editable

1. Navigate to /login
2. Verify email field is visible
3. Verify field accepts text input

TC_UI_002 — Password field masks input

1. Navigate to /login
2. Click password field
3. Type TestPass123!
4. Verify input is shown as bullets/asterisks, not plain text

TC_UI_003 — Sign in button is disabled until both fields are filled

1. Navigate to /login
2. Verify Sign in button is disabled
3. Fill email; verify button is still disabled
4. Fill password; verify button is now enabled

TC_UI_004 — Layout is responsive on mobile

1. Set viewport to 375x667 (iPhone)
2. Navigate to /login
3. Verify all fields stack vertically and are visible without horizontal scroll

TC_FN_001 — Successful login with valid credentials

1. Navigate to /login
2. Enter admin@example.com as email
3. Enter Sup3rSecret! as password
4. Click "Sign in"
5. Verify redirect to /dashboard and welcome message displays user name

TC_FN_002 — Failed login with wrong password

1. Enter valid email and wrong password
2. Click "Sign in"
3. Verify error message: Invalid email or password
4. Verify user remains on /login

TC_FN_003 — Login is case-insensitive for email

1. Enter ADMIN@EXAMPLE.COM with correct password
2. Verify login succeeds (emails are case-insensitive)

TC_FN_004 — Remember me keeps user logged in

1. Check "Remember me" and login successfully
2. Close and re-open browser
3. Navigate to /dashboard and verify user is still logged in

TC_VAL_001 — Empty email field shows required error

Leave email empty, click Sign in, verify error: Email is required.

TC_VAL_002 — Invalid email format shows format error

Enter not-an-email, click Sign in, verify error: Please enter a valid email address.

TC_VAL_003 — Empty password field shows required error

Enter valid email, leave password empty, click Sign in, verify error: Password is required.

TC_VAL_004 — SQL injection in email field is rejected

Enter ' OR '1'='1 as email and any password. Verify error message (no SQL executed).

TC_VAL_005 — XSS in email field is sanitized

Enter <script>alert('xss')</script> as email. Verify error message (script not executed).

TC_SEC_001 — Rate limiting after 5 failed attempts

Enter wrong password 5 times; verify account is temporarily locked and rate-limit message displayed.

TC_SEC_002 — Password field has correct autocomplete

Inspect password field; verify autocomplete="current-password" is set (or off for high security).

TC_SEC_003 — HTTPS is enforced

Navigate to http://example.com/login; verify redirect to https://example.com/login.

TC_SEC_004 — Session token is set with HttpOnly and Secure flags

Login successfully, inspect cookies in DevTools, verify session cookie has HttpOnly and Secure flags.

TC_SEC_005 — Login response doesn't leak which field is wrong

Enter valid email + wrong password and verify error: Invalid email or password (NOT Wrong password). This prevents email enumeration attacks.

For more secure-by-design patterns, see our Security Testing for QA guide.

TC_A11Y_001 — All form fields have associated labels

Inspect email field; verify <label for="email"> exists.

TC_A11Y_002 — Tab order is logical

Press Tab repeatedly; verify focus order: email → password → remember me → sign in.

TC_A11Y_003 — Screen reader announces field labels

Focus email field with screen reader enabled; verify it announces Email, edit text.

TC_A11Y_004 — Error messages have role="alert"

Trigger a validation error; inspect error element and verify role="alert" is set.

TC_PERF_001 — Login page loads in under 2 seconds

1. Clear cache
2. Navigate to /login
3. Measure load time
4. Verify load completes in < 2000ms

For load and stress patterns on the auth endpoint, see k6 vs JMeter.

TC_ID: TC_FN_001
Title: Successful login with valid credentials
Preconditions: User account exists; user is logged out
Priority: High
Linked Requirement: REQ-AUTH-001
Steps:
  1. Navigate to /login
  2. Enter "admin@example.com" as email
  3. Enter "Sup3rSecret!" as password
  4. Click "Sign in"
Expected Result: User is redirected to /dashboard with welcome message

Not all test cases are equal. Use this priority framework:

P0 — Critical (must pass before every release)

• TC_FN_001 (successful login)
• TC_SEC_003 (HTTPS enforced)
• TC_SEC_004 (HttpOnly cookies)

P1 — High (run on every build)

• TC_FN_002 (failed login)
• TC_VAL_001 / TC_VAL_003 (required fields)
• TC_SEC_001 (rate limiting)

P2 — Medium (run on every PR)

• TC_UI_001–004 (UI rendering)
• TC_FN_003 / TC_FN_004 (case-insensitive email, remember me)
• TC_VAL_002 / TC_VAL_004–005 (validation edge cases)

P3 — Low (run weekly or pre-release)

• TC_A11Y_001–004 (accessibility)
• TC_PERF_001 (performance)

This prioritization helps you build a fast smoke suite (P0+P1) that runs in < 5 minutes, plus a deeper regression that runs nightly. For more, see our Manual Testing Complete Guide and the ISTQB Foundation Study Guide.

• Manual Testing Complete Guide
• Test Pyramid Explained
• Software Testing Interview Questions
• Playwright Complete Guide
• ISTQB Foundation Exam Guide
• OWASP Top 10 (official)

Original SoftwareTestPilot research relevant to manual QA:

• Login-page test coverage benchmarks (2026) — which coverage areas ship real production defects.
• Test pyramid benchmarks (2026) — real ratios vs the Cohn model.
• Shift-left benchmarks (2026) — defect cost by lifecycle stage.
• QA salary benchmarks (2026) and QA jobs hiring now.

The login page in 2026 is no longer a username + password form. Any modern coverage set has to include passkeys (WebAuthn), magic-link + OTP fallback, bot / credential-stuffing defense and session hygiene. Add these 12 cases to any classic login suite:

1. Passkey enrol on a Chrome desktop then login on iOS Safari (cross-device).
2. Passkey enrol succeeds, browser storage cleared → fallback to email OTP works.
3. Magic link is single-use and expires after 10 minutes.
4. Magic link opened in a different browser than requested rejects with clear copy.
5. OTP is rate-limited to 5 attempts per 15 min per email.
6. OTP is rate-limited per IP to defeat credential stuffing.
7. Login triggers device fingerprint check; new device sends verification email.
8. Session cookie is HttpOnly, Secure, SameSite=Lax and 24h max age.
9. Refresh token rotation invalidates the previous token.
10. Concurrent login on 5+ devices does not silently drop older sessions unless policy says so.
11. Password reset link cannot be reused after successful reset.
12. Login page is behind a CAPTCHA-less bot defense (e.g. Cloudflare Turnstile) that does not block accessibility users.

Automate 1, 3, 5, 8, 9, 11 in Playwright with the real WebAuthn virtual-authenticator API; leave 2, 4, 7, 12 for a manual exploratory charter each release.