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 example25
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
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.Open the login page
- 2.Enter the registered email and correct password
- 3.Select Sign in
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.Enter the registered email and an incorrect password
- 2.Select Sign in
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.Leave the email and password fields empty
- 2.Select Sign in
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.Submit incorrect credentials repeatedly up to the documented threshold
- 2.Attempt one additional login
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.Use Tab to move through the fields and controls
- 2.Submit the form using the keyboard
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.Sign out
- 2.Use the browser Back button
- 3.Attempt to open a protected page directly
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.Enter an invalid email format
- 2.Enter any password
- 3.Select Sign in
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.Enter the registered email with leading and trailing spaces
- 2.Enter the correct password
- 3.Select Sign in
Preserve password case sensitivity
Precondition
A password containing mixed case exists.
Expected result
Authentication is rejected because passwords remain case-sensitive.
Steps
- 1.Enter the correct email
- 2.Change the case of one password character
- 3.Select Sign in
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.Enter a password
- 2.Toggle visibility on and off
- 3.Submit the form
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.Select Forgot password
- 2.Review the destination and account field
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.Open the protected URL while signed out
- 2.Review the redirect and returned content
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.Allow the session to expire
- 2.Attempt a protected action
- 3.Sign in again
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.Supply an untrusted external return URL
- 2.Complete authentication
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.Submit invalid credentials or empty fields
- 2.Navigate through the error summary and fields
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.Enter valid credentials
- 2.Press Enter from the password field
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.Enter valid credentials
- 2.Activate Sign in repeatedly while the request is pending
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.Enter the inactive account credentials
- 2.Select Sign in
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.Enter the locked account credentials
- 2.Select Sign in
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.Open the login page
- 2.Use autofill
- 3.Submit the form
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.Submit the form with multiple invalid fields
- 2.Observe focus and error announcements
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.Choose the identity provider
- 2.Complete provider authentication
- 3.Return to the application
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.Start social sign-in
- 2.Cancel at the provider
- 3.Return to the application
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.Begin authentication
- 2.Alter the callback state or code
- 3.Submit the callback
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.Open login on the mobile viewport
- 2.Enter credentials using the on-screen keyboard
- 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
Password reset test cases covering OTP delivery, expiry, one-time use, password policy, account discovery and active-session behaviour.
OTP testingOTP test cases covering valid verification, expiry, one-time use, resend behaviour, attempt limits, privacy and input boundaries.
Registration testingExample registration test cases for required fields, duplicate accounts, password rules, verification, accessibility and input boundaries.
Mobile app testingMobile application test cases covering installation, permissions, connectivity, interruptions, orientation, accessibility and supported devices.
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