Manual testing guide

25 Login Page Test Cases with Examples

A login flow protects user accounts and often becomes the first point of failure for authentication, validation and session management. These examples provide a review-ready starting point, but should be adjusted to your product’s actual identity rules.

Example requirement

A registered user can sign in with a valid email address and password. Invalid credentials must show a safe error message, repeated failed attempts must be controlled, and successful login must create a secure session.

Generate test cases for this example

25

Test cases

5

Coverage types

14

High priority

CSV

Export format

How to test login functionality

Start with the critical authentication path, then cover the account states and browser behaviours that commonly cause production defects.

  • Verify valid, invalid, locked and inactive account states.
  • Test required fields, email formats and password case sensitivity.
  • Confirm logout, session expiry and protected-route access.
  • Check password managers, keyboard use and accessible errors.

25 example test cases

Filter the coverage, switch between card and table views, then copy or export the cases you need. Replace assumptions with the confirmed rules, environments and risks of your product.

Showing 25 of 25 cases

LOGIN-001FunctionalHigh priority

Sign in with valid credentials

Precondition

An active registered account exists.

Expected result

The user is authenticated and taken to the authorised landing page.

Steps

  1. 1.Open the login page
  2. 2.Enter the registered email and correct password
  3. 3.Select Sign in
LOGIN-002NegativeHigh priority

Reject an incorrect password

Precondition

An active registered account exists.

Expected result

Authentication is rejected with a safe message that does not reveal which credential was incorrect.

Steps

  1. 1.Enter the registered email and an incorrect password
  2. 2.Select Sign in
LOGIN-003NegativeHigh priority

Validate required login fields

Precondition

The login page is open.

Expected result

Submission is blocked and each required field receives clear validation feedback.

Steps

  1. 1.Leave the email and password fields empty
  2. 2.Select Sign in
LOGIN-004SecurityHigh priority

Handle repeated failed attempts

Precondition

The account protection policy is configured.

Expected result

The configured rate limit, delay or account-protection control is applied without exposing account details.

Steps

  1. 1.Submit incorrect credentials repeatedly up to the documented threshold
  2. 2.Attempt one additional login
LOGIN-005AccessibilityMedium priority

Navigate and submit using only the keyboard

Precondition

The login page is open with keyboard input available.

Expected result

Focus is visible, follows a logical order and every required action is keyboard accessible.

Steps

  1. 1.Use Tab to move through the fields and controls
  2. 2.Submit the form using the keyboard
LOGIN-006SecurityHigh priority

Prevent reuse of a session after logout

Precondition

The user is signed in.

Expected result

Protected information remains inaccessible and the user is required to authenticate again.

Steps

  1. 1.Sign out
  2. 2.Use the browser Back button
  3. 3.Attempt to open a protected page directly
LOGIN-007NegativeMedium priority

Reject an invalid email format

Precondition

The login page accepts an email address.

Expected result

Submission is blocked and the email field receives clear validation feedback.

Steps

  1. 1.Enter an invalid email format
  2. 2.Enter any password
  3. 3.Select Sign in
LOGIN-008UsabilityMedium priority

Trim accidental spaces around the email

Precondition

An active registered account exists.

Expected result

The documented whitespace rule is applied consistently and the user receives an understandable result.

Steps

  1. 1.Enter the registered email with leading and trailing spaces
  2. 2.Enter the correct password
  3. 3.Select Sign in
LOGIN-009SecurityHigh priority

Preserve password case sensitivity

Precondition

A password containing mixed case exists.

Expected result

Authentication is rejected because passwords remain case-sensitive.

Steps

  1. 1.Enter the correct email
  2. 2.Change the case of one password character
  3. 3.Select Sign in
LOGIN-010UsabilityMedium priority

Use the password visibility control safely

Precondition

The password field has a visibility control.

Expected result

Visibility changes only when requested, the value is unchanged and the control has an accessible name.

Steps

  1. 1.Enter a password
  2. 2.Toggle visibility on and off
  3. 3.Submit the form
LOGIN-011FunctionalMedium priority

Open the forgotten-password flow

Precondition

Password recovery is enabled.

Expected result

The user reaches the approved password-recovery flow without losing necessary context.

Steps

  1. 1.Select Forgot password
  2. 2.Review the destination and account field
LOGIN-012SecurityHigh priority

Keep protected pages inaccessible before login

Precondition

A protected page URL is known.

Expected result

No protected data is exposed and the user is directed to authentication or an authorised error page.

Steps

  1. 1.Open the protected URL while signed out
  2. 2.Review the redirect and returned content
LOGIN-013SecurityHigh priority

Handle an expired session

Precondition

A signed-in session can be expired.

Expected result

The action is blocked safely, reauthentication is requested and the user can continue according to the product rule.

Steps

  1. 1.Allow the session to expire
  2. 2.Attempt a protected action
  3. 3.Sign in again
LOGIN-014SecurityHigh priority

Prevent open redirects after authentication

Precondition

The login flow supports a return URL.

Expected result

The user is redirected only to an approved internal destination.

Steps

  1. 1.Supply an untrusted external return URL
  2. 2.Complete authentication
LOGIN-015AccessibilityMedium priority

Announce validation errors to assistive technology

Precondition

A screen reader is available.

Expected result

Errors are announced, associated with the relevant fields and understandable without colour alone.

Steps

  1. 1.Submit invalid credentials or empty fields
  2. 2.Navigate through the error summary and fields
LOGIN-016UsabilityMedium priority

Sign in using the Enter key

Precondition

Valid credentials are available and focus is inside the form.

Expected result

The form submits once and produces the same result as selecting Sign in.

Steps

  1. 1.Enter valid credentials
  2. 2.Press Enter from the password field
LOGIN-017SecurityHigh priority

Prevent duplicate submissions

Precondition

The login endpoint can be delayed safely.

Expected result

Only one authentication attempt is processed and the interface communicates the pending state.

Steps

  1. 1.Enter valid credentials
  2. 2.Activate Sign in repeatedly while the request is pending
LOGIN-018NegativeHigh priority

Authenticate an inactive account safely

Precondition

An inactive test account exists.

Expected result

Access is denied with approved guidance that does not disclose sensitive account state.

Steps

  1. 1.Enter the inactive account credentials
  2. 2.Select Sign in
LOGIN-019SecurityHigh priority

Authenticate a locked account safely

Precondition

A locked test account exists.

Expected result

Access remains blocked and the response follows the documented recovery policy.

Steps

  1. 1.Enter the locked account credentials
  2. 2.Select Sign in
LOGIN-020UsabilityMedium priority

Support password manager autofill

Precondition

A password manager contains valid credentials for the site.

Expected result

The correct fields are populated and authentication works without exposing or clearing the password unexpectedly.

Steps

  1. 1.Open the login page
  2. 2.Use autofill
  3. 3.Submit the form
LOGIN-021AccessibilityMedium priority

Return focus to the first invalid field

Precondition

The login form is open.

Expected result

Focus moves predictably to an error summary or first invalid field and every error is programmatically associated.

Steps

  1. 1.Submit the form with multiple invalid fields
  2. 2.Observe focus and error announcements
LOGIN-022FunctionalHigh priority

Complete social sign-in successfully

Precondition

An approved social identity provider and linked test account are available.

Expected result

The correct application account is authenticated and receives only authorised access.

Steps

  1. 1.Choose the identity provider
  2. 2.Complete provider authentication
  3. 3.Return to the application
LOGIN-023NegativeMedium priority

Cancel social sign-in

Precondition

Social sign-in is available.

Expected result

No session is created and the user can retry or choose another login method.

Steps

  1. 1.Start social sign-in
  2. 2.Cancel at the provider
  3. 3.Return to the application
LOGIN-024SecurityHigh priority

Reject a tampered authentication callback

Precondition

A test environment permits safe callback manipulation.

Expected result

The callback is rejected and no session or account link is created.

Steps

  1. 1.Begin authentication
  2. 2.Alter the callback state or code
  3. 3.Submit the callback
LOGIN-025UsabilityMedium priority

Keep login usable on a mobile viewport

Precondition

A supported mobile viewport is available.

Expected result

Fields, errors and the submit action remain visible and operable without horizontal scrolling.

Steps

  1. 1.Open login on the mobile viewport
  2. 2.Enter credentials using the on-screen keyboard
  3. 3.Submit the form

Coverage checklist

  • Confirm the approved account-lockout or rate-limiting rule before testing.
  • Test session expiry, logout and direct access to protected URLs together.
  • Avoid error messages that confirm whether a specific email address exists.
  • Include keyboard, screen-reader labelling and password-manager behaviour.
  • Repeat core coverage for supported identity providers such as Google or Microsoft when applicable.

Common defects

  • • The form reveals whether an email address exists.
  • • Logout leaves protected pages available through browser history.
  • • Repeated clicks create overlapping authentication requests.
  • • Keyboard focus is lost when an error appears.
  • • The return URL permits redirection to an untrusted website.

Suggested test data

  • • Active, inactive and locked accounts
  • • Valid and invalid email formats
  • • Correct and incorrect case-sensitive passwords
  • • Expired sessions and protected URLs
  • • Approved and untrusted return URLs

Automation notes

  • • Automate the stable happy path, required-field checks and common invalid-credential paths.
  • • Use API or fixture setup for account states instead of coupling every test to registration.
  • • Keep rate-limit and lockout tests isolated so they do not block the shared automation account.

Frequently asked questions

What should login page test cases cover?+

Cover valid access, invalid credentials, required fields, account states, rate limits, sessions, logout, accessibility and safe error messages.

Should login security tests be automated?+

Stable checks such as session invalidation and protected-route access can be automated, while penetration testing and abuse testing need controlled environments and specialist review.

How many login test cases are enough?+

There is no universal number. Start with the highest-risk authentication and recovery rules, then add cases for your identity providers, account policies and supported devices.

Related test case examples

Generate cases for your own requirement

Paste your real user story, choose the coverage categories and receive structured manual test cases you can review and export.

Open the free generator