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

Login packs authentication, session creation, validation messaging, lockouts, and recovery into one small screen. Test cases for a login page must cover more than valid credentials: user enumeration, open redirects, broken sessions, and authorization entry after a successful sign-in.

This guide gives you a complete way to design test cases for a login page: requirements questions, scenario map, positive and negative examples, security and accessibility checks, a reusable table, common mistakes, and a prioritization model. Use it for web apps, admin portals, and SaaS products where email and password login is still core.

Why Login Page Testing Deserves Extra Care

Login failures block users completely. Login defects also create security incidents. That combination makes login high risk even when the UI looks simple.

Typical risks:

• Valid users cannot enter the product.
• Invalid users can enter the product.
• Attackers learn which emails are registered.
• Sessions persist after logout.
• Lockout logic is missing or locks the wrong accounts.
• Redirects send users to unsafe destinations.
• Error messages leak stack traces or internal IDs.
• Mobile and desktop validation behave differently.

Because login is reused constantly, one defect multiplies across every release. Treat it as a product capability, not a form demo.

Clarify Requirements Before Writing Test Cases for Login Page Flows

Before you write cases, extract rules. If documentation is incomplete, list assumptions and get confirmation.

Functional questions

• Which identifiers are allowed: email, username, phone, all of them?
• Is password case sensitive?
• Is login rate limited?
• What happens after success: dashboard, last visited page, role home?
• Is "remember me" supported, and for how long?
• Is MFA required for all users or only some roles?
• Are social login and SSO in scope for this page?
• Can users with unverified email log in?
• Are inactive, suspended, or deleted accounts handled differently?

Security questions

• Are error messages generic for wrong password and unknown user?
• Is account lockout temporary or admin controlled?
• Are cookies Secure, HttpOnly, and SameSite configured as required?
• Is HTTPS enforced?
• Are open redirects blocked on return URL parameters?
• Is captcha triggered after repeated failures?

UX and accessibility questions

• Can users complete login by keyboard only?
• Are field labels and errors announced for assistive tech?
• Are password show/hide controls accessible?
• Do validation messages appear inline, on submit, or both?

Write these answers into a short rules sheet. Your test cases should map to those rules, not to guesswork. For broader case writing technique, use the foundation guide on how to write test cases.

Scenario Map for a Login Page

Convert requirements into scenarios first. Scenarios become cases later.

Core authentication scenarios

• Valid credentials login.
• Invalid password.
• Unknown account identifier.
• Blank identifier.
• Blank password.
• Both fields blank.
• Invalid identifier format.
• Leading or trailing spaces in email or username.
• Copy-pasted password with hidden characters.
• Case variation in email if policy ignores case.
• Case variation in password if policy is case sensitive.

Account state scenarios

• Active verified user.
• Unverified email user.
• Locked user.
• Suspended user.
• Password expired user.
• User forced to reset password on next login.
• Deleted or deactivated user.

Session and navigation scenarios

• Redirect to default home after login.
• Redirect to deep link after login.
• Reject malicious redirect targets.
• Refresh after login keeps session.
• Logout clears session.
• Back button after logout does not show protected content.
• Concurrent login from second device if policy defines it.

Optional feature scenarios

• Remember me enabled.
• Remember me disabled.
• MFA challenge success.
• MFA challenge failure.
• SSO entry and return.
• Social login success and cancel.
• Captcha after N failures.
• Language or locale specific validation messages.

Non-functional scenarios

• Keyboard-only login.
• Screen reader accessible labels and errors.
• Slow network submit behavior.
• Double submit of login button.
• SQL injection style input.
• Script tags in identifier field.

This map is intentionally broader than a beginner list. You will prioritize later.

Test Case Template for Login

Use a consistent format so reviewers can scan coverage quickly.

Test Case ID:
Title:
Requirement Reference:
Priority:
Type: Positive | Negative | Boundary | Security | Accessibility | Regression
Preconditions:
Test Data:
Steps:
  1.
  2.
  3.
Expected Result:
Actual Result:
Status:
Notes:

Compact table form for suite design:

Field	Example
ID	TC-LOGIN-001
Title	Verify successful login with valid email and password
Priority	High
Preconditions	Active user exists, user is logged out
Data	buyer@example.com / ValidPass#2026
Expected	Dashboard loads, authenticated session created

Test Cases for a Login Page: Core Functional Coverage

Positive cases

ID	Title	Preconditions	Test data	Expected result	Priority
TC-LOGIN-001	Valid email and password login	Active verified user, logged out	Valid email, valid password	User is authenticated and lands on default home	High
TC-LOGIN-002	Valid username login if supported	Active user with username	Valid username, valid password	Login succeeds using username identifier	High
TC-LOGIN-003	Redirect to original deep link	User tried to open /orders while logged out	Valid credentials, return URL /orders	After login, user lands on /orders	High
TC-LOGIN-004	Role-based landing page	Admin user exists	Admin credentials	Admin lands on admin home, not buyer home	High
TC-LOGIN-005	Login after successful password reset	Password just reset	New password	Login succeeds with new password only	High
TC-LOGIN-006	Remember me keeps session per policy	Remember me enabled in requirements	Valid credentials, remember me on	Session persists for configured duration	Medium

Validation and negative cases

ID	Title	Steps summary	Expected result	Priority
TC-LOGIN-010	Submit with blank email	Leave email empty, enter password, submit	Email required message, no authentication	High
TC-LOGIN-011	Submit with blank password	Enter email, leave password empty, submit	Password required message, no authentication	High
TC-LOGIN-012	Submit with both fields blank	Submit empty form	Required field messages, no request success	High
TC-LOGIN-013	Invalid email format	Enter user@, enter password, submit	Format validation, authentication not attempted or safely rejected	Medium
TC-LOGIN-014	Wrong password	Valid email, wrong password	Generic invalid credentials message, no session	High
TC-LOGIN-015	Unknown email	Unregistered email, any password	Same generic failure behavior as wrong password if policy requires	High
TC-LOGIN-016	Inactive account	Inactive user credentials	Access denied with approved message, no session	High
TC-LOGIN-017	Locked account	Locked user credentials	Lockout message or generic denial per policy	High
TC-LOGIN-018	Unverified email login policy	Unverified user	Either blocked with verify prompt or allowed, matching requirement	High
TC-LOGIN-019	Leading/trailing spaces in email	buyer@example.com	Trimmed acceptance or explicit validation, consistently	Medium
TC-LOGIN-020	Password with leading space character	Password that includes intentional spaces if allowed	Behavior matches password policy exactly	Medium

Detailed worked example: wrong password

Test Case ID: TC-LOGIN-014
Title: Verify wrong password is rejected with safe messaging
Requirement Reference: AUTH-LOGIN-AC3
Priority: High
Type: Negative / Security
Preconditions:
  - Account buyer@example.com exists and is active
  - Account is not locked
  - User is logged out
Test Data:
  - Email: buyer@example.com
  - Password: WrongPass#000
Steps:
  1. Open the login page over HTTPS.
  2. Enter buyer@example.com in the email field.
  3. Enter WrongPass#000 in the password field.
  4. Submit the form.
  5. Attempt to open a protected URL directly.
Expected Result:
  - Login fails.
  - A generic invalid credentials message is shown.
  - Message does not state that the email exists.
  - No authenticated session cookie or token is issued.
  - Protected URL redirects back to login.
  - Failed attempt counter increases if lockout is enabled.

This level of expected result detail is what separates useful cases from vague "check invalid login" notes.

Boundary and Data-Oriented Login Cases

Login fields still have boundaries. Use ideas from boundary value analysis and equivalence partitioning.

Examples:

• Email local part at maximum accepted length.
• Email longer than maximum accepted length.
• Password at minimum length.
• Password one character below minimum if validated client-side.
• Password at maximum length.
• Password above maximum length.
• Unicode characters in email local part if product claims support.
• Very long password paste that could break UI or API payload limits.
• Empty unicode whitespace only values.

ID	Title	Data idea	Expected
TC-LOGIN-030	Min length password login if policy allows	Password exactly min length and valid	Success if password meets all rules
TC-LOGIN-031	Below min length password	Password length min-1	Validation error, no auth
TC-LOGIN-032	Max length password	Password exactly max length	Success or accepted processing
TC-LOGIN-033	Over max length password	Password max+1	Validation error or safe server rejection
TC-LOGIN-034	Extremely long email string	500+ char email-like string	No crash, clear validation or 4xx handling

Security Test Cases for Login Page

Security cases are mandatory for login, even in functional suites.

Messaging and enumeration

• Wrong password and unknown user produce indistinguishable responses if policy requires anti-enumeration.
• Response timing should not obviously differ in a way product security forbids. Perfect timing equality is hard, but gross differences may be in scope for security review.
• Error text never includes stack traces, SQL errors, or user database IDs.

Brute force and lockout

ID	Title	Expected
TC-LOGIN-040	Five failed attempts lock account if policy is five	Account locked after threshold
TC-LOGIN-041	Attempt during lockout window	Login blocked even with correct password
TC-LOGIN-042	Lockout expires after configured time	Login works again after expiry if temporary
TC-LOGIN-043	Captcha appears after threshold	Captcha required before further attempts
TC-LOGIN-044	Lockout is per account not global IP only if required	Other users can still log in

Document exact thresholds from requirements. Do not invent "five attempts" if product uses three or ten.

Session and cookie security

• After login, session token exists with required flags.
• After logout, session token is invalidated server-side.
• Old session token cannot access APIs after logout.
• Password change invalidates other sessions if required.
• Login over HTTP redirects to HTTPS if HTTPS is required.

Injection and abuse inputs

Examples of inputs to attempt in identifier or password fields:
- ' OR '1'='1
- admin'--
- <script>alert(1)</script>
- ../../etc/passwd
- extremely long repeated characters

Expected result for these is safe rejection or harmless storage, no authentication bypass, no script execution in admin or logs rendering contexts you own, and no server crash.

Open redirect

If login supports ?next= or ?returnUrl=:

• Allow internal paths such as /dashboard.
• Reject external targets such as https://evil.example.
• Reject protocol-relative tricks and encoded bypass attempts according to security rules.

ID	Title	Return URL	Expected
TC-LOGIN-050	Safe internal redirect	/settings/profile	Lands on profile after login
TC-LOGIN-051	External redirect blocked	https://evil.example	Ignored or blocked, safe fallback home
TC-LOGIN-052	Encoded external redirect blocked	URL-encoded external target	Still blocked

MFA, SSO, and Social Login Cases

If your login page includes these, do not stop at password cases.

MFA

• Valid password then valid MFA code succeeds.
• Valid password then invalid MFA code fails and does not create full session.
• MFA code reuse behavior matches policy.
• MFA timeout expires correctly.
• Recovery code path works and is rate limited.
• User cannot skip MFA by browsing directly to a protected route mid-challenge.

SSO

• SSO button sends user to identity provider.
• Successful IdP login returns linked app session.
• User cancels at IdP and returns safely.
• Unlinked enterprise account is handled with clear messaging.
• Clock skew or assertion errors show safe failure.

Social login

• First-time social login creates or links account per policy.
• Existing linked account signs in.
• Denied permission on provider side fails gracefully.
• Email conflict with existing password account follows merge policy.

These often need separate high priority suites because failures are common around account linking.

UX, Accessibility, and Reliability Cases

UX

• Password mask is on by default.
• Show password toggle works and is easy to discover.
• Caps lock warning appears if product supports it.
• Field focus order is logical: identifier, password, submit.
• Enter key submits when focus is in password field.
• Double clicking submit does not create duplicate sessions or confusing errors.

Accessibility

• Every input has an accessible name.
• Error messages are associated with fields.
• Focus moves to first error or a summary according to design system.
• Color is not the only error signal.
• Keyboard user can reach show password and submit controls.

Reliability

• Slow network: button shows pending state and avoids silent failure.
• API 500: user sees recoverable error, not a blank page.
• Offline: clear failure state.
• Browser autofill still allows successful submit.

Session Lifecycle Cases After Login

Login testing is incomplete without post-login session checks.

1. Login success creates access to protected pages.
2. Browser refresh keeps user logged in while session is valid.
3. Logout removes access.
4. Back button after logout does not display cached private data in a usable authenticated state.
5. Session timeout forces re-authentication.
6. Concurrent session rules are enforced if product limits devices.

Example:

Title: Verify protected page is inaccessible after logout
Steps:
  1. Log in with valid credentials.
  2. Open /account/billing.
  3. Confirm billing content is visible.
  4. Log out.
  5. Use browser back or paste /account/billing.
Expected:
  - User must authenticate again.
  - Billing data is not shown as an authenticated view.

Prioritizing Login Test Cases

You rarely execute every possible case on every build. Prioritize.

Priority	Include
P0 Smoke	Valid login, invalid credentials, logout session clear, HTTPS page load
P1 Release	Validation, lockout, redirect safety, role landing, unverified/locked states
P2 Deep	Boundaries, remember me matrix, accessibility depth, social edge cases
P3 Exploratory	Weird unicode, unusual browsers, rare SSO failures

For CI, automate P0 and many P1 cases with stable test users. Keep destructive lockout tests carefully isolated so they do not lock shared accounts.

Test Data Setup for Login Suites

Stable login testing needs dedicated accounts:

Account	Purpose
active.buyer@example.com	Happy path
active.admin@example.com	Role redirect
locked.user@example.com	Lockout state
unverified.user@example.com	Verification policy
expired.password@example.com	Forced reset
mfa.user@example.com	MFA flow

Rules:

• Do not share passwords across all environments without a vault pattern.
• Reset lockout state in test setup or use disposable users.
• Never rely on production user data.
• Document whether email casing is normalized.

Common Mistakes When Writing Test Cases for Login Page Coverage

Mistake 1: Only testing happy path and one wrong password

Teams ship lockout bugs, redirect bugs, and session bugs because the suite stops at two cases.

Mistake 2: Expected result is "error message shown"

Which message? Does a session still get created? Can the user hit APIs anyway? Specify security-relevant outcomes.

Mistake 3: Ignoring account states

Active, locked, suspended, unverified, deleted, and password-expired users often take different code paths.

Mistake 4: Using one shared tester account for everything

One person locks the account, everyone is blocked, and results become noise.

Mistake 5: Forgetting logout and timeout

Login success with broken logout is still a serious defect.

Mistake 6: Not checking generic messaging policy

Product may require identical responses for unknown user and wrong password. If your case expects "user not found," you may be encoding a security bug as a requirement.

Mistake 7: Skipping mobile and password manager behavior

Autofill, iOS Safari quirks, and mobile keyboard flows break login more often than desktop Chrome demos suggest.

Mistake 8: Writing steps that depend on current button copy only

Prefer resilient intent: "Submit the login form" plus important labels. Update cases when UX changes, but avoid brittle essays.

Sample Mini Suite You Can Copy

Use this as a starter pack and extend with product-specific rules.

1. TC-LOGIN-001 Valid login.
2. TC-LOGIN-010 Blank email.
3. TC-LOGIN-011 Blank password.
4. TC-LOGIN-014 Wrong password.
5. TC-LOGIN-015 Unknown user safe messaging.
6. TC-LOGIN-016 Inactive account.
7. TC-LOGIN-003 Deep link redirect.
8. TC-LOGIN-051 External redirect blocked.
9. TC-LOGIN-040 Lockout threshold.
10. TC-LOGIN-060 Logout clears session.
11. TC-LOGIN-061 Timeout requires re-login.
12. TC-LOGIN-070 Keyboard-only login success.

Twelve cases will not finish a bank-grade auth system, but they already beat "test login works."

Turning Failed Login Cases Into Defects

When a case fails, write a defect with evidence: browser, account state, request status if visible, screenshots, and whether session tokens appeared. Weak bug reports slow auth fixes. Use the structure from how to write a bug report.

Bad bug title:

Login issue

Better bug title:

Active user remains authenticated on /billing after logout when using browser back

Include expected security result, not only UI text.

Automation Notes for Login Tests

Good automation candidates:

• Valid login and assert protected page marker.
• Invalid credentials and assert no protected content.
• Validation messages for required fields.
• Redirect allowlist checks with internal return URLs.
• Logout session invalidation via UI plus API probe.

Handle carefully:

• Lockout tests: use dedicated users and cleanup.
• MFA: use test secrets or bypass hooks in non-prod only.
• Captcha: test hooks, never break production captcha.

Avoid hard coding production credentials in repositories.

Example assertion mindset in plain language:

After invalid login:
- URL remains on login or approved error state
- Protected resource request returns unauthorized
- No auth cookie present, or cookie is unauthenticated

UI assertion alone is not enough if APIs still accept an accidental token.

Regression Strategy Around Login Changes

Any change to auth libraries, cookie policy, MFA, SSO, or session store should trigger login regression. Minimum set:

• Valid login.
• Invalid login.
• Logout.
• Session timeout if changed.
• Redirect rules if changed.
• One account state failure path.
• One role-based landing check.

If a production auth incident happens, add a permanent regression case with the incident ID in traceability.

Practice Exercise

Open a practice application or a QABattle challenge that includes authentication behavior. In 30 minutes:

1. Write 10 login scenarios.
2. Convert 5 into fully detailed cases with data and expected results.
3. Mark security-sensitive expectations explicitly.
4. Identify 3 automation candidates.
5. List 3 open requirement questions.

Then compare with a peer. Gaps usually appear in account states, redirects, and session invalidation. For hands-on repetition, use QABattle sign-up and run manual track battles that force you to document cases under time pressure.

Login Test Case Review Checklist

Before you call the suite done:

• Positive authentication is covered.
• Required field validation is covered.
• Invalid credentials are covered.
• Unknown user messaging matches security policy.
• Account states are covered or explicitly out of scope.
• Lockout or rate limit rules are covered if present.
• Redirect safety is covered if return URLs exist.
• Session creation, logout, and timeout are covered.
• MFA/SSO paths are covered if offered on the page.
• Accessibility smoke checks exist for the form.
• Test data accounts are stable and documented.
• Priority labels match business risk.
• Cases link to requirements or risks.

Related Flows to Test Next

Login rarely stands alone. After this suite, extend into:

• Registration and first-time login.
• Forgot password and reset token expiry.
• Change password while logged in.
• Profile email change re-verification.
• OAuth token refresh for API clients.

Registration overlaps many validation lessons. Continue with test cases for a registration form when you want the create-account side of authentication.

Conclusion

Strong test cases for a login page work do more than prove a green sign-in button. They verify identity rules, safe failure behavior, session lifecycle, redirects, account states, and the security promises users never see until something breaks. Start from requirements and risks, map scenarios, write precise expected results, and prioritize ruthlessly for smoke, release, and deep regression.

If you keep only one habit from this guide, keep this one: every login case should state what the user sees and what authenticated power the system grants or denies. That dual expectation is how login testing protects both usability and security.