Testing Examples
Complete Login Page Test Scenarios
Explore functional, negative, security, usability and accessibility scenarios for testing a modern login page.
Introduction
A complete login suite depends on authentication methods, account states, session policy, recovery flows and accessibility requirements. Use this as a risk-based checklist and remove anything your product does not support.
Requirements to confirm before testing
- Supported identity methods and account states
- Password policy, lockout policy and recovery paths
- Session lifetime, cookie attributes and logout behaviour
- Accessibility expectations and supported browsers or devices
Functional scenarios
- Valid active user can sign in
- Successful login lands on the documented destination
- Protected pages redirect unauthenticated users
- Logout ends the authenticated session
- Return URL after login is limited to allowed destinations
Field-validation scenarios
- Empty email is rejected
- Empty password is rejected
- Malformed email format is rejected
- Leading or trailing whitespace is handled according to policy
- Maximum field length is enforced
Positive scenarios
- Keyboard-only user can complete login
- Password manager autofill works with labelled fields
- Remember Me can be selected when offered
- Show or hide password control works without clearing the value
Negative scenarios
- Incorrect password is rejected
- Unknown email or username is rejected safely
- Disabled account cannot sign in
- Rapid repeated submissions do not create duplicate sessions
Security considerations
Keep this educational and defensive. Confirm transport protection, rate limiting, neutral error wording, secure cookie flags and audit events only against approved requirements. Do not run disruptive security tests against production without authorization.
- Login is served over HTTPS in environments that require it
- Error messages avoid unnecessary account enumeration
- Sensitive cookies use the documented Secure and HttpOnly settings
Session and cookie scenarios
- New session is created only after successful authentication
- Expired session requires re-authentication
- Back navigation after logout does not expose protected content
Remember Me scenarios
- Remember Me remains unchecked by default unless documented otherwise
- Remember Me persistence matches the stated duration and device scope
Password visibility scenarios
- Password is masked by default
- Visibility toggle announces state to assistive technology where applicable
Forgot Password scenarios
- Forgot Password link is reachable and labelled clearly
- Reset request for an unknown email follows the documented neutral response
Account-locking scenarios
- Repeated failed attempts trigger the documented lockout threshold
- Locked account cannot authenticate until unlock or cooldown completes
Two-factor authentication scenarios
Include these only when MFA is part of the product. Verify challenge presentation, invalid code handling and recovery options against the published policy.
- Valid MFA challenge completes login
- Invalid MFA code is rejected without creating a full session
Accessibility scenarios
- All controls have programmatic names
- Focus order is logical and visible
- Errors are associated with fields and not conveyed by colour alone
Mobile and responsive scenarios
- Primary actions remain usable on a small viewport
- Virtual keyboard does not hide the submit control permanently
Cross-browser considerations
Validate login on the browsers and devices your product officially supports. Prefer your published support matrix over an invented list.
Performance considerations
Confirm that normal login remains responsive under expected load and that slow responses provide clear pending feedback without duplicate submissions.
Example test-case table
| Test case ID | Scenario | Preconditions | Test steps | Test data | Expected result | Priority | Type |
|---|---|---|---|---|---|---|---|
| LGN-01 | Valid active account signs in | Active account exists | Enter valid credentials and submit | qa.user@example.test / ValidPass1! | Authenticated session is created and destination loads | High | Positive |
| LGN-02 | Incorrect password is rejected | Active account exists | Enter valid email with wrong password | qa.user@example.test / WrongPass1! | Access denied; no authenticated session | High | Negative |
| LGN-03 | Required fields block empty submit | Login page available | Submit with blank email and password | Blank fields | Accessible validation is shown | High | Validation |
| LGN-04 | Account locks after failed-attempt threshold | Lockout policy enabled | Submit invalid password until threshold | Repeated invalid attempts | Account becomes locked per policy | High | Security |
| LGN-05 | Logout invalidates the session | User is signed in | Sign out and open a protected URL | Authenticated session | Protected content requires authentication again | High | Session |
Common mistakes
- Testing only the happy path
- Ignoring accessibility and keyboard use
- Using real production credentials
- Assuming MFA, social login or lockout exist without confirmation
Final checklist
- Core success and failure paths are covered
- Session, recovery and lockout behaviour match documented policy
- Accessibility and mobile constraints are included where relevant
- Open questions are tracked separately from confirmed requirements
Generate a first draft from your login requirements in AutomationTekAI, then refine it with this checklist.
Frequently asked questions
What should every login suite cover first?
Prioritize valid login, invalid credentials, required fields, critical account states, session creation, logout and keyboard access.
Should login errors reveal whether an email exists?
Authentication errors should usually avoid unnecessary account-enumeration clues. Confirm the exact wording with your security and product requirements.
Can these scenarios be automated?
Many can, using controlled accounts and test environments. CAPTCHA, identity providers and risk controls may need a separate strategy.