Blog

25 Login Test Cases Every QA Engineer Should Know

A practical set of 25 login test cases covering valid access, failures, lockouts, sessions, MFA, and SSO-ready checks for modern QA teams.

QA Workflow AssistantAugust 3, 202611 min read

login
authentication
test-cases
security

Login is where users form their first reliability judgment—and where security mistakes become incidents. A thin “happy path only” suite is not enough for products that store customer data, charge cards, or expose admin tools.

Below is a concrete catalog of 25 login test cases you can adapt. Use them as a menu, not a mandate: pick by risk, architecture (password, SSO, MFA), and release scope. For writing mechanics and field quality, keep how to write QA test cases nearby.

How to use this catalog

Group cases by intent:

Access — valid credentials and landing behavior
Validation — empty/malformed inputs
Security — lockout, enumeration, transport assumptions
Session — persistence, expiry, concurrent use
Recovery adjacent — links into reset flows without duplicating that suite
Enterprise — SSO/MFA/device posture hooks

Prioritize High for anything that grants or denies access incorrectly.

Preconditions shared by most cases

Document these once at suite level:

Base URL for the target environment
Known active user, locked user, and disabled user fixtures
Password policy notes (length, complexity, breach checks)
Whether “remember me”, MFA, or SSO is enabled in this env
Rate-limit thresholds so testers do not brick shared accounts

Access and landing (cases 1–5)

1. Valid email/password reaches default home

Priority: High
Type: Positive
Expect: Authenticated session; redirect to product home/dashboard; signed-in chrome visible; no error toast.

Priority: High (if supported)
Expect: Same success path as email login; identifier type accepted per config.

3. Role-based landing for admin vs standard user

Priority: High
Expect: Admin lands on admin home or with admin nav; standard user never sees admin routes in chrome.

Priority: Medium
Steps: Open protected deep link while logged out → authenticate → land on original resource if policy allows.
Expect: No open redirect to external domains; only allowlisted internal paths.

5. Case sensitivity rules honored

Priority: Medium
Expect: Email normalization matches product rules (often case-insensitive local mailbox); passwords remain case-sensitive.

Validation and input handling (cases 6–10)

6. Empty email and password blocked

Priority: High
Type: Negative
Expect: Client or server validation; no session created; clear required-field messaging.

7. Email only / password only submit blocked

Priority: High
Type: Negative
Expect: Missing field called out; authentication not attempted successfully.

8. Malformed email format rejected

Priority: Medium
Type: Negative
Data: not-an-email, user@, @domain.com
Expect: Format error before or instead of auth success.

9. Leading/trailing spaces handling

Priority: Medium
Type: Edge
Expect: Documented trim behavior on email; passwords typically must not silently trim in ways that surprise users—assert your actual rule.

10. Extremely long input rejected safely

Priority: Medium
Type: Edge
Expect: No 500 HTML dump; controlled validation or 414/400 equivalent; app remains usable.

Failure, lockout, and abuse resistance (cases 11–16)

11. Incorrect password fails safely

Priority: High
Type: Negative
Expect: Generic auth error; no dashboard; failed-attempt counter increments if product tracks it.

12. Unknown account fails without account enumeration

Priority: High
Type: Negative / Security
Expect: Error timing and messaging do not clearly reveal “email not found” vs “bad password” unless product intentionally differs and accepts the risk.

Priority: High
Type: Negative
Expect: Access denied with disabled-state guidance; no partial session cookies that still call APIs.

Priority: High
Type: Negative
Expect: Lock messaging/recovery path; valid password still denied while locked. Expand details via password reset test cases when unlock requires reset.

15. Rapid repeated failures trigger rate limiting

Priority: High
Type: Security
Expect: Temporary throttle or CAPTCHA per policy; legitimate later attempt can succeed after cooldown.

Priority: High
Type: Security
Expect: Treated as invalid input; no stack traces; monitoring/alerting optional but useful in staging.

Session and multi-device behavior (cases 17–21)

17. Session persists across refresh within timeout

Priority: High
Type: Positive
Expect: Still authenticated after refresh; protected API calls succeed.

18. Idle timeout forces re-authentication

Priority: High
Type: Edge
Expect: After idle limit, protected pages require login; stale UI does not silently act with expired tokens.

19. Logout clears session on this browser

Priority: High
Type: Positive
Expect: Back button cannot show private data from cache without reauth when policy requires; cookies/tokens cleared or invalidated.

20. Concurrent session policy enforced

Priority: Medium–High
Type: Edge
Expect: If single-session policy exists, second login revokes or blocks the first per docs; if multi-session allowed, both work without corrupting state.

21. “Remember me” extends session only as designed

Priority: Medium
Type: Edge
Expect: With option on/off, lifetime matches specification; private device guidance remains accurate in UI copy.

MFA, SSO, and enterprise hooks (cases 22–25)

22. MFA challenge appears for enrolled user

Priority: High (if MFA shipped)
Expect: Password alone insufficient; valid second factor completes login; invalid OTP fails without granting access.

23. MFA recovery / backup codes path

Priority: High
Type: Edge
Expect: Backup code works once if designed that way; reused code fails; account not left half-authenticated.

24. SSO redirect completes and provisions or links user

Priority: High (SSO products)
Expect: IdP login returns to app; correct org/tenant binding; Just-in-time user rules honored.

25. SSO failure surfaces actionable error

Priority: Medium
Type: Negative
Expect: Denied IdP response does not create local session; error is supportable (correlation ID if you use one).

Beyond the core 25: passwordless and magic-link cases

Some products skip passwords entirely for part of the user base. These extend the catalog above rather than replacing any of the 25—add them only if the method ships.

Magic link delivers and authenticates once

Priority: High
Expect: Link email arrives promptly; clicking it authenticates; a second click on the same link is rejected or re-authenticates per documented policy—assert whichever your product actually ships.

Magic link expires on schedule

Priority: Medium
Type: Edge
Expect: After the configured window, the link fails with actionable guidance to request a new one; no silent authentication on an expired link.

Magic link opened on a different device than requested

Priority: Medium
Type: Edge
Expect: Documented policy (allow, warn, or block) is enforced consistently—cross-device magic links are a common phishing vector, so the chosen behavior should be intentional, not accidental.

Priority: High (if shipped)
Expect: Registered device completes passkey authentication without a password prompt; on unsupported browsers, the product falls back to an available method instead of a dead end.

Extending the catalog for native mobile apps

Native apps introduce token storage and deep-link concerns that web-only suites miss. Treat these as an app-specific add-on module.

Access token persists in secure storage, not plain preferences

Priority: High
Type: Security
Expect: Token lives in Keychain/Keystore or equivalent; uninstall/reinstall requires fresh login; rooted/jailbroken device handling matches your security policy if you have one.

App-to-app SSO handoff completes correctly

Priority: Medium (if applicable)
Expect: Switching from a browser-based IdP back to the app via a universal link/App Link lands the user in an authenticated state without duplicate prompts.

Priority: Medium
Type: Edge
Expect: Face/fingerprint unlock resumes an existing valid session; a revoked or expired session still requires full re-authentication even if biometrics succeed locally.

Check	Expect
Error messages translated, not left in source language	Matches selected locale
Right-to-left layout for RTL locales	Fields and buttons mirror correctly
Screen reader announces field labels and errors	Label/error programmatically associated
Keyboard-only flow completes without a mouse	Tab order reaches submit; no focus trap
High-contrast mode preserves error visibility	Error state not color-only

These are easy to skip under release pressure and expensive to skip in production, since login blocks everything downstream of it.

Traceability matrix (sample)

Case #	Intent	Suggest automation?
1–3	Core access	Yes
6–8	Validation	Yes
11–15	Security	Yes (careful with lockout fixtures)
17–19	Session	Yes
22–24	MFA/SSO	Partial — env-dependent

Manual vs automation notes

Automate stable identifiers and deterministic fixtures first. Keep abuse tests (lockout storms) in controlled jobs so shared staging users are not permanently locked. Visual checks for branded error pages can stay manual or snapshot-based.

Pair login failures with broader negative test cases patterns when you expand beyond authentication.

Maintain at least:

Fixture	Purpose
`user.active`	Happy path
`user.locked`	Lockout assertions
`user.disabled`	Admin disable path
`user.mfa`	Second-factor path
`user.sso-only`	Password login should fail if policy says so

Rotate passwords through a secrets manager. Never commit them to the repo.

Flaky login automation erodes trust in the whole suite fast, since it runs on nearly every job. A few recurring causes are worth naming explicitly:

Symptom	Likely cause	Fix direction
Intermittent timeout on submit	Shared staging rate limiter throttling CI	Dedicated CI-only test accounts outside the shared throttle bucket
Random MFA prompt on "password-only" test	Risk engine flags CI IP as new device	Allowlist CI egress IP or use a risk-exempt test tenant
Session cases fail only after deploys	Token secret rotated mid-run	Pin secrets for the run or add a warm-up retry with backoff
SSO case fails outside business hours	IdP sandbox maintenance window	Document the window; skip with a reason, not a silent retry loop

Treat each of these as a fix-the-cause task, not a "just add a retry" patch. Retries hide the exact signal login suites exist to catch.

Release strategy: what to run when

Change type	Minimum login set
Copy-only on marketing site	None or smoke #1 if shared auth header
Auth UI refactor	1, 6, 7, 11, 17, 19
Session middleware change	17–21
MFA launch	22–23 + 1
SSO launch	24–25 + tenant binding checks

For suite depth philosophy, see Basic, Standard, or Deep coverage. Tooling plans that affect how many variants you generate are outlined on Pricing; integration setup is in Docs.

FAQ

Do we need all 25 every sprint?

No. Keep 1, 6, 11, 14, 17, and 19 as a durable smoke core. Add others when the related subsystem changes.

Should error messages be identical for bad password and unknown user?

Many security programs prefer generic messaging. Test the policy you ship—not a textbook ideal that product rejected.

How do we test lockout without harming shared accounts?

Use dedicated lockout fixtures and an admin unlock API/job in non-prod. Document cooldown windows in the suite header.

Where does password reset fit?

Keep reset in its own suite—password reset test cases—and link from login only where CTA navigation matters.

Do we need separate cases for mobile web and native apps?

Only where behavior actually diverges—token storage, biometric unlock, and deep-link handoff are native-specific. Shared validation and lockout logic can stay in one case set with a platform note rather than being duplicated wholesale.

Only if the product has actually removed passwords. Many products run both in parallel during migration, which means both suites need to stay green—do not retire password cases just because a newer method shipped.

Final checklist

CTA — draft auth suites from the story pack

When authentication stories land with dense acceptance criteria, use QA Workflow Assistant to draft a first-pass login suite you can prune against this 25-case menu—especially useful before MFA or SSO milestones. Keep security wording and lockout fixtures under human ownership. Configuration steps are in Docs.