Browse the Knowledge Hub32 resources
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat 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
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
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.
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 improvementWant 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 servicesMore test case sets
View allTest cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 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 cases26 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 cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 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 cases26 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 cases24 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 cases26 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 cases25 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 cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- OWASP ASVS verification requirements for authentication, session and access control.
- OWASP Web Security Testing Guide test procedures for enumeration, injection and authorisation.
- WCAG 2.2 the success criteria behind the accessibility cases.
- ISTQB Glossary standard definitions for the testing terms used here.
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.