View all services
Talk to QA Advisor
Browse the Knowledge Hub32 resources
/Test Cases/Login page test cases

Test cases

25 login page test cases, including the ones most sets omit

Functional, negative, boundary, security, session, accessibility and compatibility coverage for the feature almost every product has. Adapt the set to your own login and download it as CSV for your test management tool.

25cases/8coverage types/7security cases/FreeCSV download

All 25 test cases, ready to copy

Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.

Last updated

25 worked examples

LOGIN-01

Log in successfully with valid credentials

TypeFunctionalPriorityHigh
Test data
Registered, active account with correct password
Expected result
Authenticated and redirected to the intended landing page. Session cookie set with HttpOnly, Secure and SameSite attributes.
LOGIN-02

Reject an incorrect password for a valid account

TypeNegativePriorityHigh
Test data
Valid email, wrong password
Expected result
Refused with a generic message. No session created. Message is identical to the unknown-account case.
LOGIN-03

Reject an unregistered email without revealing that it is unregistered

TypeSecurityPriorityHigh
Test data
[email protected] with any password
Expected result
Same generic error and the same response timing as a wrong password, so the response cannot be used to enumerate accounts.
LOGIN-04

Block submission when either field is empty

TypeNegativePriorityMedium
Test data
Empty email, empty password, and each field empty in turn
Expected result
Inline validation identifies each missing field. No request is sent for a client-blocked case.
LOGIN-05

Treat whitespace-only input as empty

TypeNegativePriorityMedium
Test data
Three spaces in each field
Expected result
Rejected as empty rather than submitted, and leading or trailing spaces in a real email are trimmed.
LOGIN-06

Reject malformed email formats

TypeNegativePriorityMedium
Test data
plainstring, missing@dot, @nodomain.com, spaces [email protected], double@@at.com
Expected result
Each is rejected with a format message before authentication is attempted.
LOGIN-07

Treat the email as case insensitive and the password as case sensitive

TypeFunctionalPriorityMedium
Test data
[email protected] with correct password, then correct email with case-altered password
Expected result
Uppercase email authenticates successfully. Case-altered password is refused.
LOGIN-08

Enforce field length boundaries

TypeBoundaryPriorityMedium
Test data
Email at 254 characters and 255, password at minimum minus one, minimum, maximum and maximum plus one
Expected result
Values inside the limits are accepted, values outside are rejected with a message naming the limit, and no server error occurs at any boundary.
LOGIN-09

Lock or throttle after repeated failed attempts

TypeSecurityPriorityHigh
Test data
Five consecutive incorrect passwords, then the correct one
Expected result
Further attempts are refused even with the correct password. The response states the lockout and retry window. The event is written to the audit log.
LOGIN-10

Resist SQL injection in the credentials fields

TypeSecurityPriorityHigh
Test data
' OR '1'='1 and admin'-- in both email and password
Expected result
Login fails normally. No database error surfaces and no authentication bypass occurs.
LOGIN-11

Resist script injection and reflected XSS

TypeSecurityPriorityHigh
Test data
<script>alert(1)</script> in the email field
Expected result
Input is escaped in any echoed error message. No script executes.
LOGIN-12

Mask the password and keep it out of logs and URLs

TypeSecurityPriorityHigh
Test data
Any password
Expected result
Characters are masked on screen, the credential is sent in the request body over HTTPS rather than the query string, and it never appears in server or analytics logs.
LOGIN-13

Redirect HTTP to HTTPS before credentials are entered

TypeSecurityPriorityHigh
Test data
Load the login page over http://
Expected result
Redirected to HTTPS. The form is never served or submitted over plain HTTP.
LOGIN-14

Honour the remember me selection

TypeSessionPriorityMedium
Test data
Log in with and without remember me, then close and reopen the browser
Expected result
With it selected the session persists for the documented period. Without it the session ends when the browser session ends.
LOGIN-15

Invalidate the session on sign out, including via the back button

TypeSessionPriorityHigh
Test data
Authenticated session, then sign out, then press browser back
Expected result
Protected pages are not accessible after sign out. The back button shows the login page or an expired notice rather than cached authenticated content.
LOGIN-16

Expire an idle session and preserve the intended destination

TypeSessionPriorityMedium
Test data
Authenticate, idle beyond the timeout, then request a protected page
Expected result
Redirected to login. After re-authenticating, the user lands on the originally requested page rather than a generic dashboard.
LOGIN-17

Reject a login attempt with a stale or tampered CSRF token

TypeSecurityPriorityHigh
Test data
Submit the form with the CSRF token removed and with it altered
Expected result
Both submissions are refused with an appropriate error and no session is created.
LOGIN-18

Handle a disabled, locked or unverified account distinctly

TypeFunctionalPriorityMedium
Test data
Correct credentials for a disabled account, a locked account and an unverified account
Expected result
Each is refused with the appropriate message and next step, such as resend verification, without revealing more than the account owner should see.
LOGIN-19

Complete the password reset journey end to end

TypeFunctionalPriorityHigh
Test data
Request reset, use the emailed link, set a new password, then log in
Expected result
Reset link works once, expires after use and after its time window, the new password authenticates, and the old password no longer does.
LOGIN-20

Operate the form with the keyboard only

TypeAccessibilityPriorityMedium
Test data
No pointing device for the duration of the test
Expected result
Every control is reachable in a logical tab order with a visible focus indicator, and the form submits with Enter (WCAG 2.1.1, 2.4.7).
LOGIN-21

Expose labels, roles and errors to a screen reader

TypeAccessibilityPriorityMedium
Test data
Screen reader enabled, submit with a blank password
Expected result
Fields have programmatic labels, the password field is identified as such, and the validation error is announced and associated with its field (WCAG 1.3.1, 3.3.1, 4.1.2).
LOGIN-22

Meet colour contrast requirements including the error state

TypeAccessibilityPriorityLow
Test data
Default state and error state
Expected result
Text and interactive elements meet WCAG AA contrast, and the error is not communicated by colour alone.
LOGIN-23

Support password managers and autofill

TypeUsabilityPriorityMedium
Test data
Saved credentials in a browser password manager
Expected result
Fields carry correct autocomplete attributes, autofill populates them, and the autofilled values submit successfully.
LOGIN-24

Behave correctly across supported browsers and breakpoints

TypeCompatibilityPriorityMedium
Test data
Latest two versions of Chrome, Firefox, Safari and Edge, plus mobile and tablet widths
Expected result
Layout, validation and submission behave consistently. On mobile the keyboard type is appropriate per field and no control is obscured by the on-screen keyboard.
LOGIN-25

Prevent duplicate submission on double click or slow network

TypeFunctionalPriorityMedium
Test data
Double click submit, and submit under throttled network conditions
Expected result
Only one authentication request is processed. The control is disabled or debounced while the request is in flight, with a visible pending state.

What goes in each field

ID

Required

Stable identifier, prefixed by module.

Test case

Required

What is being verified, in one line.

Type

Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.

Priority

Risk based. Everything touching authentication bypass, account enumeration or lockout is High regardless of how rare the path looks.

Test data

The specific values, including the invalid and boundary ones.

Expected result

Required

The precise observable outcome, including message text where the wording itself is the requirement.

How To Use This

Use it as a coverage baseline, not a copy and paste

Your login has rules this set does not know about. What travels between products is the shape of the coverage.

Start from the security block

Account enumeration, lockout, injection and session invalidation are where login defects actually hurt, and where most published sets stop short.

Add your own rules

Password policy, MFA, SSO, social login and role-based redirects are product-specific. This set gives you the frame to hang them on.

Decide what to automate

The functional, negative and boundary cases automate well. Accessibility and usability cases stay manual, because they need judgement.

Keep session cases in regression

Sign-out, back-button and expiry defects are reintroduced by unrelated changes more often than any other login behaviour.

Why This Coverage

What most published login test sets leave out

Search for login test cases and you will mostly find valid credentials, invalid password, empty fields and a remember-me check. That is roughly a fifth of the real coverage, and it omits the cases where login actually fails in production.

Account enumeration is the clearest example. If the error for an unregistered email differs from the error for a wrong password, in wording or even in response timing, an attacker can build a list of valid accounts before attempting anything else. It is a one-line test that almost never appears in published sets.

Session behaviour is the second gap. Sign-out that leaves cached authenticated pages reachable through the back button, sessions that outlive their stated timeout, and reset links that work more than once are all common, all high impact, and all invisible to a test set that stops at successful login.

Accessibility is the third. A login form that cannot be completed with a keyboard, or whose validation errors are never announced, locks people out of the product entirely. Three cases cover the essentials, and they belong in the standard set rather than in a separate audit nobody schedules.

Suggest an improvement

Want this coverage on your product?

QAble writes and executes test suites across authentication, payments and the other flows where defects cost the most.

Functional testing services

More test case sets

View all

Test cases for a registration form

Test cases
28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.

Test cases for search functionality

Test cases
28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.

Test cases for a shopping cart

Test cases
27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.

Test cases for checkout and payment

Test cases
30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.

Test cases for file upload

Test cases
28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.

Test cases for forgot password

Test cases
26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.

Test cases for OTP verification

Test cases
26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.

Test cases for user roles and permissions

Test cases
26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.

Test cases for form validation

Test cases
27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.

Test cases for a date picker

Test cases
26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.

Test cases for pagination

Test cases
24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.

Test cases for push notifications

Test cases
26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.

Test cases for reports and data export

Test cases
25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.

Test cases for a chatbot

Test cases
28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.

Sources

Need the testing done, not just the test cases?

QAble executes and automates suites like this with ISTQB-certified engineers. Start with a free QA audit of your product.

Talk to QA Advisor