How to Test a Login Page: 50+ Test Cases, Scenarios & Complete QA Checklist
A login page looks simple.
Usually, it contains only a few elements:
- Email or username
- Password
- Login button
- Forgot password link
- Remember me option
- Sign-up link
But from a QA perspective, a login page is one of the most important parts of a web application.
A login failure can prevent users from accessing the entire product.
A security problem in authentication can expose private information.
A session-management problem can allow unauthorized access.
A validation problem can create poor user experience.
A responsive design problem can make the application unusable on mobile.
And a small change to the authentication flow can break multiple downstream features.
This is why login testing should go far beyond:
"Enter username and password and click Login."
A complete login testing strategy should cover functional behavior, negative scenarios, validation, boundaries, security, sessions, usability, accessibility, browser compatibility, mobile behavior, error handling, and regression.
This guide provides a practical login testing checklist with more than 50 test scenarios that QA engineers can use when testing web applications.
---
What Is Login Testing?
Login testing is the process of verifying that an application's authentication functionality works correctly, securely, and consistently for different types of users and conditions.
The basic objective is simple:
A valid user should be able to authenticate successfully.
An invalid or unauthorized user should not be able to access protected functionality.
But real applications introduce many additional conditions.
For example:
- What happens when the password is incorrect?
- What happens after several failed attempts?
- What happens when the session expires?
- What happens if the user opens an old login link?
- What happens on a mobile device?
- What happens when JavaScript fails?
- What happens when the authentication service is unavailable?
- What happens when the user enters extremely long input?
- What happens when the user attempts to access a protected URL without logging in?
These are the scenarios that make login testing important.
---
Why Login Testing Is Important
Authentication is usually a gateway to the rest of an application.
If authentication is broken, many other features can become inaccessible.
More importantly, authentication is directly related to security.
A defect in a login workflow could potentially result in:
- Unauthorized access
- Account enumeration
- Session problems
- Weak password enforcement
- Authentication bypass
- Information disclosure
- Poor account recovery
- Unexpected account lockouts
Login is therefore both a functional and security-critical area.
For QA teams, it should usually receive high test priority.
---
Types of Login Testing
A complete login testing strategy can include several testing categories.
1. Functional Testing
Verifies that login behaves according to requirements.
2. Negative Testing
Verifies that invalid inputs and incorrect actions are handled correctly.
3. Boundary Testing
Verifies behavior around input limits.
4. UI Testing
Verifies that login elements are displayed and behave correctly.
5. Usability Testing
Verifies whether users can understand and complete the login process.
6. Security Testing
Verifies authentication-related security controls.
7. Session Testing
Verifies login sessions, expiration, logout, and protected resources.
8. Compatibility Testing
Verifies login behavior across supported browsers and devices.
9. Accessibility Testing
Verifies keyboard navigation, labels, focus behavior, and assistive-technology compatibility.
10. Performance Testing
Verifies that authentication responds appropriately under expected and high load.
A good test strategy combines these rather than relying on only functional tests.
---
Basic Login Test Cases
Let's start with the core scenarios.
Test Case 1: Login With Valid Credentials
Enter a valid registered username/email and the correct password.
Expected result:
The user is authenticated and redirected to the expected page.
---
Test Case 2: Login With Invalid Password
Enter a registered username/email with an incorrect password.
Expected result:
Authentication fails and an appropriate error message is displayed.
The user should not be granted access.
---
Test Case 3: Login With Unregistered Email
Enter an email address that does not belong to a registered account.
Expected result:
Login fails.
The application should not authenticate the user.
---
Test Case 4: Empty Username or Email
Leave the username/email field empty and enter a password.
Expected result:
Appropriate validation is displayed.
The login request should be handled according to the application's requirements.
---
Test Case 5: Empty Password
Enter a valid username/email but leave the password empty.
Expected result:
Password validation appears.
---
Test Case 6: Both Fields Empty
Click Login without entering any credentials.
Expected result:
The application should clearly indicate the required fields.
---
Test Case 7: Invalid Email Format
Enter an invalid email such as:
test@
or
user.example.com
if the application expects email-based authentication.
Expected result:
The input should be rejected or appropriately handled.
---
Test Case 8: Leading and Trailing Spaces
Enter credentials with accidental spaces.
Expected result:
Behavior should match the application's requirements.
For example, the application may trim whitespace from an email field while treating password spaces differently.
---
Test Case 9: Case Sensitivity
Test uppercase and lowercase variations.
For example:
USER@example.com
and
user@example.com
Expected behavior should match the authentication requirements.
Email identifiers are often treated differently from passwords, so this should be explicitly tested.
---
Test Case 10: Password Visibility
If a password visibility icon exists, click it.
Expected result:
The password should become visible.
Click again.
Expected result:
The password should become masked again.
---
Negative Login Test Cases
Negative testing is especially important for authentication.
The objective is not simply to verify that valid users can log in.
It is also to verify that invalid actions are rejected safely.
---
Test Case 11: Incorrect Username and Incorrect Password
Enter credentials that do not belong to any user.
Expected result:
Authentication fails.
---
Test Case 12: Valid Username With Wrong Password Repeatedly
Attempt authentication multiple times using an incorrect password.
Expected behavior should follow the application's security policy.
Possible behavior includes:
- Temporary lockout
- Rate limiting
- CAPTCHA
- Additional verification
The exact behavior depends on the requirements.
---
Test Case 13: Very Long Username
Enter an extremely long username/email.
Expected result:
The application handles the input safely without breaking the interface or producing unexpected behavior.
---
Test Case 14: Very Long Password
Enter a password significantly longer than the expected maximum.
Expected result:
The application handles the value according to its password policy.
---
Test Case 15: Special Characters
Test supported special characters in usernames and passwords.
Expected result:
Valid supported characters should be handled correctly.
---
Test Case 16: Unicode Characters
Test supported Unicode characters where applicable.
Examples may include:
- Accented characters
- Non-Latin characters
- Unicode symbols
Expected result:
The application handles input according to its supported character set.
---
Test Case 17: HTML-Like Input
Enter strings containing characters commonly used in markup.
Expected result:
The application should treat the input safely as data.
---
Test Case 18: Unexpected Input Types
If the UI or API accepts structured input, verify that unexpected types are handled safely.
For example:
- Null values
- Unexpected strings
- Numeric values
- Unexpected JSON structures
This becomes particularly important when testing authentication APIs.
---
Boundary Test Cases for Login
Input boundaries are frequently overlooked.
Suppose the requirement states:
Username:
5–50 characters
Password:
8–64 characters
Don't test only:
5 characters and 50 characters.
Test around the boundary.
---
Test Case 19: Username Below Minimum
Enter one character below the minimum.
Expected result:
Validation should behave correctly.
---
Test Case 20: Username At Minimum
Enter exactly the minimum allowed length.
Expected result:
The input should be accepted if all other requirements are satisfied.
---
Test Case 21: Username Above Maximum
Enter one character above the maximum.
Expected result:
The application should reject or safely handle the input according to the specification.
---
Test Case 22: Password Below Minimum
Enter a password shorter than the minimum.
Expected result:
Validation appears.
---
Test Case 23: Password At Minimum
Enter exactly the minimum length.
Expected result:
The password should be accepted if it satisfies the password policy.
---
Test Case 24: Password At Maximum
Enter exactly the maximum supported length.
Expected result:
The application should handle it correctly.
---
Test Case 25: Password Above Maximum
Enter a value beyond the allowed limit.
Expected result:
The application should handle the boundary safely and consistently.
---
Login UI Test Cases
Functional correctness isn't enough.
The login page must also work visually.
---
Test Case 26: Login Page Loads Correctly
Verify that all expected elements are visible.
Check:
- Logo
- Username/email field
- Password field
- Login button
- Forgot password
- Registration link
- Remember me
- Other required elements
---
Test Case 27: Login Button State
Verify whether the Login button behaves correctly when:
- Fields are empty
- One field is populated
- Both fields are populated
- Invalid data is entered
The expected behavior should match the product requirements.
---
Test Case 28: Error Message Placement
Enter invalid credentials.
Verify that the error message appears in an understandable location.
---
Test Case 29: Error Message Visibility
Verify that error messages are not:
- Hidden
- Clipped
- Overlapping
- Too small
- Outside the visible viewport
---
Test Case 30: Password Field Masking
Verify that password characters are masked by default when that is the intended behavior.
---
Test Case 31: Responsive Login Page
Test the login page on:
- Desktop
- Laptop
- Tablet
- Mobile
Verify that fields and buttons remain usable.
---
Test Case 32: Orientation Changes
On supported mobile devices, rotate between portrait and landscape.
Verify that the login interface remains usable.
---
Test Case 33: Keyboard Navigation
Navigate through the login form using the keyboard.
Verify logical focus order.
---
Test Case 34: Focus Visibility
Verify that users can clearly see which field currently has focus.
---
Login Usability Test Cases
Authentication is often the first interaction users have with an application.
Small usability problems can therefore create significant frustration.
---
Test Case 35: Clear Field Labels
Verify that users can easily understand what each field expects.
---
Test Case 36: Appropriate Error Messages
An error message should help users understand what went wrong without exposing unnecessary sensitive information.
---
Test Case 37: Password Reset Is Easy to Find
If password recovery is supported, the Forgot Password option should be easy to locate.
---
Test Case 38: Login Failure Does Not Destroy Valid Input Unnecessarily
For example, after an incorrect password, the application should behave according to its UX requirements.
Repeatedly forcing users to re-enter everything can create unnecessary friction.
---
Test Case 39: Loading State
If authentication takes time, verify that the user receives an appropriate loading state.
The UI should not appear frozen.
---
Test Case 40: Prevent Confusing Double Submission
Click the Login button multiple times quickly.
Verify that the application handles repeated submission appropriately.
---
Forgot Password Test Cases
The login experience doesn't end with successful authentication.
Account recovery is part of the authentication system.
---
Test Case 41: Forgot Password With Registered Email
Enter a registered email.
Expected result:
The password reset process begins successfully.
---
Test Case 42: Forgot Password With Unregistered Email
Enter an unregistered email.
Expected behavior should follow the application's security and UX requirements.
The system should avoid unnecessarily exposing sensitive account information.
---
Test Case 43: Invalid Email Format
Enter an invalid email.
Expected result:
Appropriate validation occurs.
---
Test Case 44: Expired Reset Link
Open an expired password reset link.
Expected result:
The user cannot use the expired link and receives appropriate guidance.
---
Test Case 45: Previously Used Reset Link
Attempt to reuse a reset link after completing the password reset.
Expected result:
The application should reject reuse when one-time reset links are required.
---
Remember Me Testing
If the application provides a "Remember Me" option, test it independently.
---
Test Case 46: Remember Me Enabled
Log in with Remember Me enabled.
Close and reopen the browser.
Verify expected session behavior.
---
Test Case 47: Remember Me Disabled
Repeat the test with Remember Me disabled.
Verify that session persistence matches the product requirements.
---
Test Case 48: Logout After Remember Me
Log in with Remember Me enabled.
Log out.
Verify that protected content cannot be accessed simply by reopening the application.
---
Session Testing
Authentication and session management are closely related.
---
Test Case 49: Session Expiration
Log in and allow the session to expire.
Attempt to access protected functionality.
Expected result:
The application requires authentication again according to its session policy.
---
Test Case 50: Direct Access to Protected URL
Without logging in, directly open a protected URL.
Expected result:
The user should not receive unauthorized access.
The application should redirect or respond according to the authentication design.
---
Test Case 51: Browser Back Button After Logout
Log in.
Navigate through protected pages.
Log out.
Press the browser Back button.
Expected result:
Previously protected content should not become accessible simply because it exists in browser history.
---
Test Case 52: Multiple Browser Tabs
Log in in one tab.
Open another tab.
Verify that authentication state behaves consistently according to the application design.
---
Security-Oriented Login Testing
Authentication testing should include security considerations.
Security testing should be performed responsibly and within authorized environments.
---
Test Case 53: Authentication Bypass
Verify that protected resources cannot be accessed without valid authentication.
---
Test Case 54: Session Protection
Verify that session identifiers and authentication state are handled securely.
---
Test Case 55: Account Enumeration Behavior
Check whether login or password recovery responses unnecessarily reveal whether a specific account exists.
The expected behavior depends on the application's security requirements.
---
Test Case 56: Rate Limiting
Test repeated authentication attempts within an authorized test environment.
Verify that security controls behave according to requirements.
---
Test Case 57: Account Lockout
If account lockout exists, verify:
- Lockout threshold
- Lockout duration
- Appropriate messaging
- Recovery process
- Administrative behavior
---
Test Case 58: Secure Logout
After logout, verify that protected resources cannot simply be accessed using an active session.
---
Browser Compatibility Testing
A login page should be tested across supported browsers.
Depending on the product's browser support matrix, this may include:
- Chrome
- Edge
- Firefox
- Safari
The objective is not necessarily to test every browser imaginable.
It is to verify all officially supported environments.
Look for:
- Broken layouts
- Input problems
- Button behavior
- Password manager issues
- Redirect problems
- JavaScript errors
- Authentication inconsistencies
---
Mobile Login Testing
Mobile users often experience login problems that aren't visible on desktop.
Test:
- Small screens
- Different viewport widths
- Portrait mode
- Landscape mode
- Touch interaction
- Keyboard behavior
- Password fields
- Autofill
- Button size
- Error messages
- Scrolling
A login button that works perfectly on desktop but is hidden behind the mobile keyboard is still a real usability problem.
---
Accessibility Testing for Login Pages
Accessibility should be part of login testing.
Check:
Keyboard navigation
Can the entire form be completed without a mouse?
Focus order
Does focus move logically?
Labels
Are fields clearly associated with their labels?
Error identification
Can users understand which field contains an error?
Focus visibility
Can users see where keyboard focus currently is?
Screen reader behavior
Are important controls and messages exposed correctly?
Contrast
Can text and controls be distinguished clearly?
Accessibility requirements vary by product and applicable standards, so testing should follow the project's accessibility criteria.
---
API-Level Login Testing
A modern application may have a UI login form backed by an authentication API.
Testing only the UI may not provide complete coverage.
The underlying API can be tested independently.
For example:
Valid credentials
Verify successful authentication response.
Invalid credentials
Verify authentication failure.
Missing parameters
Verify appropriate validation.
Invalid data
Verify safe error handling.
Expired session
Verify authentication behavior.
Authorization
Verify that authenticated users can access only resources they are authorized to access.
API-level testing can also make regression testing faster because it can validate authentication behavior without requiring the complete browser workflow every time.
---
Login Testing and Regression Testing
Authentication changes can have a large impact.
A small change to login may affect:
- User dashboard
- Profile
- Checkout
- Orders
- Payments
- Subscriptions
- Admin features
- APIs
- Notifications
This makes login a good candidate for regression testing.
A regression suite should focus on the highest-value authentication scenarios.
For example:
1. Valid login
2. Invalid password
3. Invalid user
4. Empty credentials
5. Password reset
6. Session expiration
7. Logout
8. Protected URL access
9. Remember Me
10. Account lockout
The exact suite should depend on the application's risk profile.
---
Manual Testing vs Automated Login Testing
Both approaches are useful.
Manual Testing
Manual testing is particularly useful for:
- Exploratory testing
- Usability
- Visual behavior
- New functionality
- Unexpected workflows
- Investigating failures
Automated Testing
Automation is particularly useful for:
- Repeated regression
- Stable workflows
- Multiple environments
- Frequent releases
- Cross-browser execution
- Smoke testing
A good QA strategy combines them.
---
When Should Login Tests Be Automated?
Not every login scenario needs automation.
Automate scenarios that are:
- Stable
- Repeated frequently
- Business critical
- Deterministic
- Expensive to execute manually
For example:
A successful login test is usually an excellent automation candidate.
A stable invalid-password scenario is also a good candidate.
An unusual one-time exploratory scenario may not need permanent automation.
The objective is not to automate every possible test.
The objective is to automate the tests that provide repeatable value.
---
How to Build a Login Test Suite
A practical login regression suite could start with a small number of high-value scenarios.
Smoke Tests
- Login with valid credentials
- Logout
- Access protected page
Functional Regression
- Invalid password
- Invalid email
- Empty fields
- Password reset
- Remember Me
- Session expiration
Security-Oriented Checks
- Protected URL access
- Session invalidation
- Account lockout
- Rate limiting
UI Regression
- Login layout
- Error messages
- Responsive behavior
This keeps the suite focused.
The suite can grow as the application grows.
---
A Complete Login Testing Checklist
Before signing off a login feature, QA can ask:
Functional
[ ] Valid login works
[ ] Invalid password is rejected
[ ] Invalid username/email is rejected
[ ] Empty fields are handled
[ ] Invalid email format is handled
[ ] Password rules are enforced
[ ] Login redirects correctly
[ ] Logout works
[ ] Forgot Password works
[ ] Remember Me behaves correctly
Negative
[ ] Invalid credentials
[ ] Missing username
[ ] Missing password
[ ] Both fields empty
[ ] Long username
[ ] Long password
[ ] Boundary values
[ ] Unsupported input
[ ] Repeated failed attempts
Session
[ ] Session starts correctly
[ ] Session persists correctly
[ ] Session expires correctly
[ ] Logout invalidates access
[ ] Protected URLs require authentication
[ ] Browser Back does not expose protected content
UI
[ ] Fields display correctly
[ ] Login button works
[ ] Password masking works
[ ] Error messages display correctly
[ ] Loading state works
[ ] Responsive layout works
[ ] Mobile keyboard does not break the form
Accessibility
[ ] Keyboard navigation
[ ] Focus order
[ ] Focus visibility
[ ] Labels
[ ] Error identification
[ ] Screen reader compatibility
Compatibility
[ ] Supported desktop browsers
[ ] Supported mobile browsers
[ ] Different viewport sizes
[ ] Portrait mode
[ ] Landscape mode
---
Common Login Bugs QA Engineers Should Watch For
Some authentication bugs appear repeatedly across web applications.
1. Login button remains disabled incorrectly
Users cannot authenticate even with valid input.
2. Error messages disappear too quickly
Users don't have enough time to understand the problem.
3. Password field behaves incorrectly
Characters may become visible unexpectedly or input may be lost.
4. Session remains active after logout
This can create serious security concerns.
5. Protected pages remain accessible after logout
Browser caching or incorrect session handling may expose previously protected content.
6. Mobile layout breaks
The login button or input fields become difficult to use.
7. Incorrect redirect
Users authenticate successfully but are sent to the wrong page.
8. Password reset link remains usable after use
One-time recovery links should follow the application's security requirements.
9. Account lockout behaves incorrectly
Users may become locked too easily or security controls may fail to activate.
10. Authentication failures create confusing messages
Users may not understand how to recover.
These are exactly the kinds of problems that a structured login testing strategy is designed to catch.
---
How AI Can Help With Login Testing
AI can be useful here, but it should support the testing process rather than replace QA judgment.
For example, AI can help generate:
- Positive scenarios
- Negative scenarios
- Boundary cases
- Additional edge cases
- Test data
- Test documentation
A QA engineer can provide the login requirements and ask:
"Generate potential scenarios that aren't already covered."
The QA engineer then reviews the results.
AI can also potentially analyze test failures and group related problems.
But the core testing strategy should still be based on application requirements and risk.
---
How to Automate Login Testing With RoboQA
This is where an AI-powered browser testing platform can become useful.
Instead of manually translating every login scenario into automation code, a tester can describe the desired workflow.
For example:
"Open the website, navigate to the login page, enter a valid email and password, click Login, and verify that the dashboard appears."
A browser testing platform can use that description as the starting point for execution.
Additional scenarios can then be created around:
- Invalid credentials
- Empty fields
- Password visibility
- Forgot password
- Navigation after login
- Logout
- Protected pages
The important idea is that the QA engineer describes the testing intent rather than having to manually build every browser interaction from scratch.
With RoboQA, the goal is to make browser-based testing more accessible to teams that don't want every test to require a manually written automation script.
---
What a Good Login Testing Strategy Looks Like
A mature login testing strategy does not consist of 100 random test cases.
It is structured around risk.
Start with:
Critical workflow
Can users authenticate?
Then:
Negative behavior
Can invalid users be rejected correctly?
Then:
Security
Can unauthorized users be prevented from accessing protected resources?
Then:
Session management
Does authentication remain valid for the correct amount of time?
Then:
Usability
Can users understand and complete the login process?
Then:
Compatibility
Does it work across supported environments?
Then:
Regression
Can important login behavior be continuously verified?
This creates much stronger coverage than simply increasing the number of test cases.
---
Final Login Testing Checklist
If you need a short version to use during QA execution, start here:
1. Verify valid login.
2. Verify invalid password.
3. Verify invalid username/email.
4. Verify empty username.
5. Verify empty password.
6. Verify both fields empty.
7. Verify invalid email format.
8. Verify password masking.
9. Verify password visibility toggle.
10. Verify input boundaries.
11. Verify long inputs.
12. Verify special characters.
13. Verify Unicode behavior where supported.
14. Verify login button behavior.
15. Verify validation messages.
16. Verify error messages.
17. Verify loading state.
18. Verify duplicate submission.
19. Verify Forgot Password.
20. Verify expired reset links.
21. Verify used reset links.
22. Verify Remember Me.
23. Verify logout.
24. Verify session expiration.
25. Verify protected URL access.
26. Verify browser Back after logout.
27. Verify multiple tabs.
28. Verify account lockout.
29. Verify rate limiting.
30. Verify authentication security controls.
31. Verify keyboard navigation.
32. Verify focus behavior.
33. Verify accessibility.
34. Verify desktop browsers.
35. Verify mobile browsers.
36. Verify responsive layout.
37. Verify portrait mode.
38. Verify landscape mode.
39. Verify API authentication.
40. Verify authorization after authentication.
41. Verify redirect behavior.
42. Verify error recovery.
43. Verify network failure behavior.
44. Verify authentication service failure behavior.
45. Verify regression scenarios.
46. Verify UI consistency.
47. Verify password reset flow.
48. Verify session invalidation.
49. Verify critical downstream workflows.
50. Verify the complete login journey end-to-end.
---
Conclusion
Testing a login page is much more than checking whether a user can enter an email and password.
A complete login testing strategy considers:
- Functional behavior
- Negative scenarios
- Boundary conditions
- Validation
- Security
- Sessions
- Password recovery
- UI
- Usability
- Accessibility
- Mobile behavior
- Browser compatibility
- APIs
- Regression
- End-to-end workflows
The most effective QA teams don't simply create the largest number of test cases.
They identify the scenarios that represent the greatest risk and make sure those scenarios are continuously validated.
Manual testing remains valuable for exploration, usability, and unexpected behavior.
Automation is valuable for stable, repeatable regression scenarios.
AI can assist with generating scenarios, finding potential gaps, analyzing results, and reducing repetitive work.
And AI-powered browser testing platforms can potentially connect test intent with actual browser execution.
For teams building modern web applications, the goal should be simple:
Don't just test whether login works.
Test how login can fail.
Test what happens when the user makes mistakes.
Test what happens when the network fails.
Test what happens when sessions expire.
Test what happens after logout.
Test what happens on mobile.
Test what happens when users behave unexpectedly.
And most importantly, test whether an unauthorized user can ever get somewhere they shouldn't.
A login page may contain only a few fields and a button.
From a quality perspective, it can represent the gateway to the entire application.
That's why login testing deserves a structured, risk-based testing strategy.