Blog
100+ Login Page Test Cases: Functional, Security & API Testing
Rishabh Kumar
Published on
Table of contents
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Every application begins at the login page. It is the first interaction a user has with your product, the first security checkpoint your system enforces, and the first place trust is either built or broken. A single authentication defect can expose millions of user records, cripple enterprise operations, or erode customer confidence overnight.
Writing test cases for login page functionality is not a checklist exercise. It is a strategic discipline that spans functional correctness, security hardening, performance resilience, cross browser compatibility, and accessibility compliance. With AI reshaping how tests are authored, maintained, and executed, the standard for what constitutes thorough login testing has fundamentally shifted.
What Are Test Cases for a Login Page?
Test cases for a login page are structured scenarios designed to validate that an application's authentication mechanism functions correctly, securely, and reliably under every conceivable condition. Each test case defines a specific input, action, expected outcome, and pass/fail criteria.
Unlike simple form validation, login page testing intersects multiple disciplines: functional testing verifies credential handling works as designed, security testing probes for vulnerabilities like SQL injection and brute force exposure, performance testing measures response under concurrent user load, and UI testing ensures visual consistency across devices and browsers.
For enterprise applications running on platforms like SAP, Oracle, Salesforce, or Microsoft Dynamics 365, login testing also encompasses single sign on (SSO) flows, SAML and OAuth2 token exchanges, multi factor authentication (MFA), and role based access control (RBAC) validation.
Types of Test Cases for Login Page
Login test cases fall into distinct categories, each targeting a different dimension of quality.
Test case type | What it checks | Example |
|---|---|---|
Functional | Credential validation, session management and redirect logic, with valid and invalid inputs | Valid credentials redirect the user to the dashboard |
Security | Injection attacks, session hijacking, credential exposure and brute force protection | Session token changes after successful login |
Performance | Response times, concurrent user handling and behaviour under stress | 1,000 concurrent logins complete within the agreed threshold |
UI and visual | Layout consistency, responsive design and element alignment across browsers and devices | Login page adapts correctly on mobile screens |
API | Authentication endpoints, token generation and session lifecycle, separate from the UI | Invalid credentials return HTTP 401 with a generic error |
Accessibility | WCAG 2.2 compliance for screen readers, keyboard navigation and assistive technologies | The full login flow can be completed using only a keyboard |
BDD | Login scenarios written in Gherkin so QA, developers and business stakeholders can collaborate | "Given I am on the login page, when I enter valid credentials..." |
Enterprise authentication | SSO, SAML, OAuth2 and role-based access at scale | SAML login returns the user with the correct role and permissions |
Functional Test Cases for Login Page
Functional test cases form the foundation of login validation. They verify that the authentication system processes credentials accurately and handles every user path gracefully.
Positive Login Test Cases
These validate the expected "happy path" scenarios:
Valid username and valid password redirects to the dashboard
Enter a registered username and correct password. Click the login button. Verify the user is redirected to the correct post-login destination, a valid session token is created, and the user's name or profile information appears on the dashboard. This is the baseline case that must pass before any other testing has meaning.
Login using the minimum allowed character length for both fields
Enter a username and password each containing exactly the minimum number of characters the application permits. Verify login succeeds. This case confirms the minimum boundary is inclusive and that the validation logic uses greater-than-or-equal-to rather than strictly greater-than.
Login using the maximum allowed character length for both fields
Enter a username and password each at exactly the maximum permitted character length. Verify login succeeds and the full-length values are processed without truncation. This confirms upper boundary handling is correct and that the system does not silently cut long values.
Remember Me persists the session after browser restart
Log in with the Remember Me checkbox selected. Close and reopen the browser. Verify the user is still authenticated without re-entering credentials. Also verify that the persisted session respects the configured maximum duration and expires correctly after that period.
Login using a valid email address as the username
Enter a valid email address in the username field and the corresponding password. Verify login succeeds. This case is necessary when the application accepts both usernames and email addresses, confirming the authentication system correctly identifies email format as a valid identifier.
Login using a valid phone number as the username where supported
Where the application supports phone number authentication, enter a valid registered phone number in the correct format for the configured locale. Verify login succeeds. Also test with and without country code prefixes to confirm format handling.
Successful login with MFA enabled via SMS, authenticator app, and hardware key
Complete the first factor with valid credentials. Verify the MFA prompt appears correctly. Complete the second factor using each supported method separately: an SMS one-time code, an authenticator app TOTP code, and a hardware security key where supported. Verify full session creation after each successful second-factor completion.
Login with mixed case username where the system is case insensitive
Enter the username with alternating uppercase and lowercase characters, for example User@Example.COM instead of user@example.com. Verify login succeeds if the system is documented as case insensitive. Verify login fails with an appropriate error if the system is case sensitive. This case catches implementations where case sensitivity is inconsistently applied.
Login using special characters in the password
Enter a password containing special characters including at sign, hash, dollar sign, percentage, caret, ampersand, asterisk, and parentheses. Verify login succeeds and the special characters are processed correctly without being stripped, encoded incorrectly, or interpreted as commands.
Login via social authentication providers
Test each configured social provider separately: Google, Microsoft, Apple, and GitHub. For each, verify the redirect to the provider's authentication page is correct, the callback after successful authentication creates a valid session, and the user profile data is correctly mapped from the provider's claims.
Login after a successful password reset
Complete a password reset flow from start to finish. Log in using the new password. Verify login succeeds. Also verify that the old password is rejected after the reset is complete. This case confirms the full reset flow is connected to the authentication system correctly.
Login after account recovery through email verification
Complete an account recovery flow triggered by email verification. Log in after recovery is confirmed. Verify login succeeds and the account is fully restored with the correct permissions and data.
Login across multiple browsers with consistent behaviour
Test the complete login flow on Chrome, Firefox, Safari, and Edge. Verify behaviour is identical across all four: successful authentication, correct redirect, session creation, and visual rendering. Document any browser-specific differences as defects.
Login with different locale and language settings applied
Change the browser or application language setting and complete the login flow. Verify that error messages, field labels, placeholder text, and notifications are displayed in the correct language and that authentication itself is not affected by locale settings.
Login using passkeys and biometric authentication on supported devices
On devices and browsers that support passkeys (WebAuthn), register a passkey and sign in with it. Verify fingerprint, face recognition or device PIN produces a valid session without a password.
Also verify the fallback to password login works when the passkey is unavailable, and that a passkey registered on one device can't be used to sign in from an unregistered one.
Negative Login Test Cases
Negative test cases verify system resilience against incorrect, malicious, and unexpected inputs. These cases are where the most commercially significant defects hide.
Incorrect password for a valid username displays a generic error message
Enter a valid username with an incorrect password. Verify the error message does not identify which field failed. The correct response is a generic message such as "Invalid email or password" rather than "Incorrect password." Specific field identification enables credential stuffing by confirming which half of a credential pair is valid.
Incorrect username with a valid password displays the same generic error
Enter an unregistered username with any password. Verify the error message is identical to the one shown for an incorrect password. This prevents username enumeration, which is a common attack vector where valid usernames are discovered by comparing error message differences.
Empty username field with a valid password shows a required field validation message
Leave the username field empty and enter a valid password. Click the login button. Verify a field-level validation message appears on the username field specifically rather than a generic page-level error. Verify the form does not submit and no authentication attempt is made.
Empty password field with a valid username shows a required field validation message
Enter a valid username and leave the password field empty. Click the login button. Verify field-level validation appears on the password field. Verify no authentication attempt is made against the backend.
Both fields left empty triggers validation on both fields simultaneously
Click the login button without entering anything in either field. Verify validation messages appear on both fields at the same time rather than sequentially. Sequential validation that only shows one error at a time forces users to submit repeatedly, which is a poor experience and slows down legitimate users.
Username containing only whitespace characters is rejected
Enter a username consisting only of spaces or tab characters. Verify the field validation rejects the input with an appropriate message. Verify no authentication attempt is made. Whitespace-only values that are accepted without validation can cause unexpected behaviour in authentication systems that trim inputs before processing.
Password containing only whitespace characters is rejected
Enter a password consisting only of spaces. Verify rejection with a validation message. Some implementations accept whitespace-only passwords, which creates both a security weakness and unexpected behaviour for users who accidentally submit empty-looking fields.
Login with a deactivated or suspended account displays an appropriate notification
Attempt to log in with credentials belonging to a deactivated or suspended account. Verify the error message communicates that the account is inactive rather than returning the generic invalid credentials message. The message should direct the user to contact support or provide a recovery path, without revealing the specific reason for deactivation if that information is sensitive.
Login with an expired account prompts renewal or support contact
Attempt to log in with credentials belonging to an account that has passed its expiry date, which is common in enterprise environments with time-limited access. Verify the response clearly communicates account expiry and provides a clear next step.
Exceeding the maximum failed login attempts triggers account lockout
Attempt login with incorrect credentials repeatedly until the configured lockout threshold is reached. Verify the account locks and subsequent attempts are blocked regardless of whether correct credentials are used. The lockout threshold and duration should match the documented security policy exactly.
Login attempt after account lockout displays lockout duration and recovery instructions
After triggering account lockout, attempt login again immediately. Verify the error message clearly states how long the account is locked and what steps are available to unlock it. Verify the lockout persists for the full configured duration and does not reset prematurely.
Credentials containing leading or trailing whitespace are handled correctly
Enter a valid username and password with a leading space before the username and a trailing space after the password, simulating copy-paste behaviour. Verify the system either trims whitespace and authenticates successfully, or rejects the input with a clear message. Inconsistent whitespace handling is a common source of support tickets and user frustration.
Special characters and markup in the username field are handled safely
Enter characters like angle brackets, quotes and ampersands in the username field. Verify the form either rejects them with a clear validation message or accepts them safely, and that nothing is echoed back unescaped in the error message.
Unexpected characters in credential fields return a clean error
Enter quotes, semicolons and double dashes in both fields. Verify the login fails with the standard generic error, and that no database or stack trace details appear in the response.
Excessively long strings in either field are gracefully rejected
Enter a string of 10,000 or more characters in the username field and separately in the password field. Verify the system rejects the input with HTTP 400 or a client-side validation message rather than timing out, crashing, or returning HTTP 500. Long string handling defects can be exploited in denial-of-service scenarios.
Security Test Cases for Login Page
Authentication security is non negotiable. These test cases probe the login page for the vulnerabilities attackers target most frequently.
All login traffic is transmitted over HTTPS with valid TLS certificates
Attempt to access the login page over plain HTTP. Verify the request is either rejected or redirected to the HTTPS version before any credentials are transmitted. Verify the TLS certificate is valid, not expired, and issued by a trusted certificate authority. Inspect the TLS version and cipher suite to confirm they meet current security standards.
Passwords are never stored or transmitted in plain text
Verify through network inspection that the password field value is transmitted as part of an encrypted HTTPS request and never appears in plain text in network traffic, browser developer tools, or application logs. Confirm with the development team or through database inspection that passwords are stored using a modern hashing algorithm such as bcrypt, scrypt, or Argon2 rather than MD5 or SHA-1.
SQL injection via login fields does not compromise the system
Enter structured SQL injection payloads into both fields and verify the authentication system uses parameterised queries or prepared statements that prevent injection. Confirm no database errors are returned in the response body, which would indicate the injection payload reached the database layer.
XSS payloads in username and password inputs are sanitised
Enter cross-site scripting payloads in both fields. Verify the inputs are sanitised before storage and that no script content is echoed back in error messages, audit logs, or any other output surface. XSS in authentication error messages can be used to steal session tokens from administrators reviewing logs.
Session tokens are regenerated after successful authentication
Capture the session token or cookie value before authentication. Complete a successful login. Capture the session token again. Verify the token value has changed. Reusing the pre-authentication session token after login is a session fixation vulnerability that allows attackers who can set a victim's session token to hijack their session.
Session cookies include Secure, HttpOnly, and SameSite attributes
Inspect the Set-Cookie header in the response after successful authentication. Verify the Secure attribute is present, which prevents the cookie from being transmitted over plain HTTP. Verify HttpOnly is present, which prevents JavaScript from reading the cookie. Verify SameSite is set to Strict or Lax, which prevents cross-site request forgery.
Brute force protection activates after consecutive failed attempts
Send repeated failed authentication requests and verify the system responds with account lockout, rate limiting, or a CAPTCHA challenge after the configured threshold is reached. Verify the protection activates within the documented number of attempts and that the lockout duration matches the security policy.
Login page does not reveal whether a username exists in the system
Test authentication with a known valid username and wrong password. Test with a completely fabricated username and any password. Compare the error messages, response times, and HTTP status codes for both scenarios. Any detectable difference enables username enumeration.
Clickjacking protection headers are present
Inspect the HTTP response headers for the login page. Verify that either X-Frame-Options is set to DENY or SAMEORIGIN, or that a Content Security Policy header includes a frame-ancestors directive that prevents the login page from being embedded in an iframe on an attacker's site.
Password field masks input by default with an optional visibility toggle
Verify the password field uses type="password" and that characters are masked immediately on entry. Verify the Show Password toggle, if present, correctly reveals and re-masks the password. Verify that the revealed password does not persist in browser history or autocomplete suggestions.
Forgot password flow does not disclose whether an email is registered
Enter a registered email address in the forgot password flow. Enter an unregistered email address. Verify the response message is identical in both cases. A message that confirms an email was sent only for registered addresses enables username enumeration through the password reset flow.
Session tokens expire after the configured idle timeout period
Authenticate and obtain a session token. Leave the session idle for longer than the configured timeout period. Attempt to use the session. Verify the request is rejected and the user is required to authenticate again. Verify the timeout value matches the documented security policy.
Concurrent sessions from a second device are handled correctly
Authenticate from one device or browser. Authenticate again from a second device or browser using the same credentials. Verify the application behaves according to its documented concurrent session policy: either the first session is invalidated, both sessions remain active, or the user is notified of the concurrent login attempt.
Password managers and paste work correctly on the login form
Inspect the login form and verify the username field uses autocomplete="username" and the password field uses autocomplete="current-password". Verify a password manager can fill both fields, and that pasting into the password field isn't blocked.
Failed login attempts are logged with timestamps and IP addresses
Complete several failed login attempts. Access the application's audit log or coordinate with the development team to verify that each failed attempt is recorded with the timestamp, the username that was attempted, and the source IP address. This audit trail is required for security incident investigation and compliance in most regulated industries.
Enterprise Authentication Test Cases
Enterprise applications introduce authentication complexity that consumer applications rarely encounter. These test cases address SSO, SAML, OAuth2, and role based access at scale.
SAML SSO login redirects the user to the identity provider login page correctly
Click the SSO login option. Verify the browser is redirected to the correct identity provider URL. Verify the SAML authentication request contains the correct issuer, assertion consumer service URL, and name ID policy. Any misconfiguration in the SAML request prevents SSO from functioning.
Successful SAML assertion returns the user to the service provider with a valid session
Complete authentication at the identity provider. Verify the SAML response is correctly received and validated by the service provider. Verify the user is redirected to the correct post-login destination with a valid session established. Verify the session contains the user attributes mapped from the SAML assertion.
Expired or invalid SAML assertion displays an appropriate error and does not create a session
Replay a previously valid but now expired SAML assertion. Verify the service provider rejects it with an appropriate error message. Verify no session is created. Also test with a SAML assertion that has been tampered with by modifying a field value after signing. Verify rejection.
OAuth2 authorisation code flow completes successfully with token exchange
Initiate OAuth2 login. Verify the authorisation code is correctly returned to the callback URL. Verify the application exchanges the authorisation code for an access token and refresh token. Verify the tokens have the correct scopes and expiry values.
OAuth2 refresh token rotation generates a new access token without re-authentication
Allow the access token to expire or force expiry. Verify the application uses the refresh token to obtain a new access token without requiring the user to log in again. Verify the old access token is invalidated after rotation and that the new token has the correct expiry.
OpenID Connect login retrieves user profile claims correctly
Complete an OpenID Connect login flow. Verify the ID token contains the correct user profile claims including email, name, and any custom claims required by the application. Verify the claims are correctly mapped to the user's profile in the application.
Multi-tenant login routes users to the correct organisational tenant
Log in using an email address belonging to a specific organisational tenant. Verify the user is routed to the correct tenant environment and not to another organisation's data. Multi-tenant routing failures are among the most serious authentication defects in enterprise applications.
RBAC assigns the correct permissions after login based on user role
Log in with accounts belonging to different roles: administrator, standard user, read-only user, and any other configured roles. Verify each account receives exactly the permissions defined for its role. Verify no role receives permissions belonging to a higher-privileged role.
Microsoft Entra ID (formerly Azure Active Directory) SSO integrates correctly across all supported browsers
Complete the Microsoft Entra ID SSO flow on Chrome, Firefox, Safari, and Edge. Verify successful authentication and correct session creation on each browser. Microsoft Entra ID SSO behaviour can differ across browsers due to third-party cookie restrictions and browser-specific security policies.
Okta SSO handles session timeout and re-authentication gracefully
Authenticate via Okta SSO. Allow the Okta session to expire without activity. Attempt to perform an action in the application that requires authentication. Verify the user is redirected to Okta for re-authentication and returned to their original destination after completing authentication.
SCIM provisioned user accounts can authenticate immediately after provisioning
Provision a new user account via SCIM. Without any manual intervention, attempt to authenticate with the provisioned account. Verify login succeeds immediately after provisioning completes. Delays between provisioning and authentication availability indicate synchronisation issues.
Federated login across multiple identity providers resolves to the correct user profile
If the application supports federation across multiple identity providers, authenticate using each provider. Verify that when the same user authenticates through different providers, they are resolved to the same user profile rather than creating duplicate accounts.
Step-up authentication triggers additional verification for sensitive operations
After completing standard authentication, attempt to access a feature or perform an operation that requires elevated verification such as changing account settings or approving a high-value transaction. Verify the application prompts for step-up authentication and that access is denied until the additional factor is completed.
Just-in-time user provisioning creates accounts on first SSO login
Configure a user in the identity provider who does not yet exist in the application. Complete SSO authentication for the first time. Verify the application automatically creates a user account with the correct attributes and permissions based on the identity provider's claims without requiring manual provisioning.
Session management enforces the organisation's maximum session duration policy
Authenticate and verify the session token or cookie has an expiry time that matches the organisation's configured maximum session duration. Verify the session is invalidated after that duration regardless of activity, not just after an idle timeout.
Performance Test Cases for Login Page
Login pages must remain responsive under peak load conditions. A slow or unresponsive authentication experience directly impacts user adoption and revenue. The thresholds below are common starting points. Adjust them to your own SLAs and expected traffic.
Average login page load time is under two seconds on desktop and mobile
Measure the time from initial page request to the login form being fully interactive on desktop and mobile devices using standard network conditions. Record results across ten runs and verify all fall under two seconds. Report the median, 95th percentile, and maximum values separately.
Load test with 1,000 concurrent login attempts completes within acceptable thresholds
Simulate 1,000 simultaneous login attempts using a load testing tool. Measure the response time for each request and verify all complete successfully within the documented acceptable threshold. Record error rates, average response time, and 95th percentile response time.
Stress test with 10,000 simultaneous authentication requests produces no unhandled errors
Ramp up to 10,000 simultaneous authentication requests and monitor the system's behaviour. Verify the application degrades gracefully under extreme load rather than crashing or returning unhandled HTTP 500 errors. Record the point at which errors begin to appear and compare against documented capacity limits.
Authentication API response time under normal load is under 200ms
Measure the response time of the authentication endpoint under typical load conditions representing normal production traffic levels. Verify 95% of requests complete within 200 milliseconds. Authentication latency directly affects perceived application responsiveness.
Authentication API response time under peak load stays within SLA thresholds
Repeat the API response time measurement during the peak load simulation. Verify response times remain within the documented SLA thresholds. Record and report any degradation compared to normal load.
Login performs acceptably on throttled network connections
Simulate 3G and 4G network conditions and measure login page load time and authentication completion time under each. Verify the experience remains usable on constrained connections, particularly important for applications accessed by mobile users in areas with limited connectivity.
Server resource utilisation stays within acceptable bounds under peak authentication load
During the peak load test, monitor CPU usage, memory consumption, and network bandwidth on the authentication servers. Verify utilisation stays within documented acceptable limits and does not indicate resource exhaustion that would cause degradation for non-authentication functionality.
Database connection pooling handles concurrent authentication queries without timeout
During the concurrent login load test, monitor database connection pool utilisation. Verify authentication queries are served within normal response time and that connection pool exhaustion does not cause authentication failures or timeouts.
MFA-enabled login completes within acceptable total authentication time
Measure the total time from initiating login to completing MFA and establishing a session. Verify this falls within the documented acceptable threshold. MFA adds inherent latency. The threshold should account for reasonable user interaction time but flag infrastructure delays.
CDN and caching configurations reduce static asset load times
Inspect network requests during login page load and verify that static assets including CSS, JavaScript, and images are served from a CDN with appropriate cache headers. Verify repeat visits load faster due to browser caching. Misconfigured caching causes unnecessary load on origin servers and slows page load for returning users.
Time to interactive for the login page is within threshold across all supported browsers
Measure the time to interactive metric for the login page on Chrome, Firefox, Safari, and Edge. Verify the login form is interactive within the documented threshold on each browser. Large differences between browsers indicate browser-specific rendering performance issues.
System recovers correctly after a simulated backend failure during authentication
Simulate a backend service failure mid-authentication by taking down a dependency such as the identity provider or database connection during an active login attempt. Verify the application returns a clear error to the user rather than hanging indefinitely, and that the system resumes normal authentication processing once the dependency recovers.
UI and Visual Test Cases for Login Page
Visual consistency and usability directly affect user confidence at the point of authentication.
Login page layout matches the approved design specification on desktop viewports
Compare the rendered login page against the approved design on viewports at standard desktop widths of 1280px, 1440px, and 1920px. Verify spacing, alignment, typography, colours, and element positioning match the specification within the agreed tolerance.
Responsive layout adapts correctly on tablet viewports
Test the login page at tablet viewport widths from 768px to 1024px in both portrait and landscape orientations. Verify the layout reflows correctly, elements remain usable and properly spaced, and no content is clipped or overlapping.
Responsive layout adapts correctly on mobile viewports
Test the login page at mobile viewport widths from 320px to 480px. Verify the layout is fully usable on small screens, input fields are appropriately sized for touch interaction, and the login button is reachable without horizontal scrolling.
Username field is focused automatically on page load
Load the login page and verify the username field receives focus without requiring the user to click. Automatic focus is a usability feature that reduces friction for the most common action a user performs on the page.
Tab order moves logically through all interactive elements
Use keyboard Tab key navigation to move through the login page. Verify the tab order follows a logical sequence: username field, password field, remember me checkbox if present, forgot password link, login button. An illogical tab order creates accessibility failures and poor keyboard usability.
Login button is disabled until both fields contain input where implemented
Where the application disables the login button until both fields are populated, verify the button is non-interactive when either or both fields are empty and becomes active once both contain at least one character. Verify the visual state of the button clearly communicates whether it is active or disabled.
Error messages appear inline below the relevant field
Trigger validation errors on each field individually. Verify error messages appear directly below the specific field that caused the error rather than as a banner at the top of the page. Inline field-level errors communicate the problem location immediately and reduce user effort to identify and correct the issue.
Placeholder text is descriptive and disappears on focus
Verify placeholder text in the username and password fields provides useful guidance on the expected format. Verify the placeholder text disappears when the user clicks into the field and reappears if the field is cleared. Placeholder text that persists after input begins creates readability issues.
Show Password toggle displays and hides password characters correctly
Click the Show Password toggle. Verify the password field switches from masked input to visible text and the toggle icon or label changes to indicate the current state. Click the toggle again. Verify the field returns to masked mode. Verify the toggle does not affect the password value itself.
Login page displays correctly in both light mode and dark mode
View the login page with the system or browser set to light mode and separately to dark mode. Verify the page design correctly adapts to both, that text remains readable against the background in both modes, and that brand elements retain the correct appearance.
Brand logos, colours, and typography match the organisation's style guide
Compare the login page against the organisation's brand style guide. Verify logo positioning, colour values, font families, font weights, and font sizes all match the specification. Brand inconsistency on the login page damages credibility at the first point of contact.
Login page renders correctly when browser zoom is set to 200%
Set the browser zoom level to 200%. Verify all content remains visible and usable, no elements overlap or become inaccessible, and horizontal scrolling is not required. Users who rely on browser zoom for accessibility should be able to complete authentication without impairment.
CAPTCHA element renders and functions correctly across browsers
Where a CAPTCHA is present, verify it renders correctly on Chrome, Firefox, Safari, and Edge. Verify the CAPTCHA challenge can be completed successfully on each browser and that successful CAPTCHA completion allows the login attempt to proceed.
API Authentication Test Cases
Testing the authentication layer at the API level catches defects that UI testing alone can miss.
POST request with valid credentials returns HTTP 200 and a valid token
Send a POST request to the authentication endpoint with correct credentials. Verify the response returns HTTP 200 with a body containing a valid access token. Verify the token is correctly formatted, contains the expected claims, and has a non-expired expiry time.
POST request with invalid credentials returns HTTP 401 with a generic error body
Send a POST request with an incorrect password for a valid username. Verify the response returns HTTP 401. Verify the error body does not identify which credential was incorrect and does not contain any information that could be used for username enumeration.
POST request with missing required fields returns HTTP 400 with field-specific validation errors
Send a POST request with the username field omitted from the request body. Verify the response returns HTTP 400 with a validation error identifying the missing field. Repeat with the password field omitted. Verify the error clearly identifies which required field is absent.
Authentication token has the correct expiration time encoded
Decode the JWT or inspect the token response. Verify the expiration claim or expiry field contains a timestamp that matches the configured token lifetime. Tokens with incorrect expiry values either expire too soon, causing unnecessary re-authentication, or too late, creating a security window longer than intended.
Token payload contains the expected claims
Decode the authentication token and verify it contains all required claims: user ID, role or permission scope, tenant identifier where applicable, and any custom claims required by the application. Missing claims cause downstream authorisation failures that are difficult to diagnose.
Expired token is rejected by protected endpoints with HTTP 401
Use an access token that has passed its expiry time to make a request to a protected endpoint. Verify the response returns HTTP 401 with a clear indication that the token has expired. Verify the endpoint does not return data or partially process the request with an expired token.
Rate limiting on the authentication endpoint returns HTTP 429 after threshold is exceeded
Send authentication requests at a rate that exceeds the configured rate limit threshold. Verify the response changes to HTTP 429 Too Many Requests after the threshold is reached. Verify the response includes a Retry-After header indicating when requests will be accepted again.
Refresh token endpoint issues a new access token correctly
Send a valid refresh token to the refresh endpoint. Verify the response returns a new access token with a fresh expiry time. Verify the new access token is accepted by protected endpoints. Verify the old access token is either invalidated or remains valid until its original expiry depending on the application's documented behaviour.
Revoking a token immediately invalidates it across all services
Revoke a valid access token using the revocation endpoint. Immediately use the revoked token to make a request to a protected endpoint. Verify the request is rejected with HTTP 401. If the application uses multiple services, verify the revoked token is rejected across all services rather than just the service that processed the revocation.
Authentication endpoint rejects requests with a tampered token signature
Take a valid JWT, change a claim in the payload such as the user role, and send it to a protected endpoint without re-signing it. Verify the request is rejected with HTTP 401 and that the altered claim is never trusted.
Accessibility Test Cases for Login Page
Login pages must be usable by everyone, including users who rely on assistive technologies.
All form fields have associated label elements for screen reader compatibility
Inspect the HTML of the login form. Verify each input field has a properly associated label element using either a for attribute matching the field's id, an aria-label attribute, or an aria-labelledby attribute pointing to a visible label. Screen readers use these associations to announce field names to users who cannot see the visual labels.
Login page achieves WCAG 2.2 AA colour contrast ratios
Use a colour contrast analyser to check the contrast ratio between text and background colours throughout the login page. Verify all standard text achieves at least 4.5:1 contrast ratio and all large text achieves at least 3:1. Check field borders, placeholder text, and button labels in addition to primary content.
Entire login flow is completable using keyboard-only navigation
Place hands on keyboard only and navigate through the complete login flow without touching the mouse or trackpad. Verify it is possible to: focus each field, enter credentials, activate the show password toggle if present, activate the remember me checkbox if present, and submit the form entirely by keyboard.
Focus indicators are visible on all interactive elements
Tab through all interactive elements on the login page. Verify a clear visual focus indicator is visible on each element as it receives focus. The focus indicator must be visible enough to be useful for keyboard users and must not rely solely on colour to communicate focus state.
Error messages are announced to screen readers via ARIA live regions
Using a screen reader, enter invalid credentials and submit the form. Verify the error message is announced automatically by the screen reader without the user needing to navigate to the error. Error announcements require ARIA live regions or focus management that moves to the error message after submission.
Login page has a logical heading hierarchy
Inspect the heading structure of the login page. Verify there is a single H1 that represents the page title. Verify no heading levels are skipped, meaning an H3 does not appear without a preceding H2. A logical heading hierarchy allows screen reader users to navigate efficiently and understand the page structure.
CAPTCHA provides an accessible alternative
Where a CAPTCHA is present, verify an accessible alternative is available. An audio CAPTCHA satisfies this requirement for users with visual impairments. Where neither visual nor audio CAPTCHA is accessible, an alternative verification method must be provided. A CAPTCHA with no accessible alternative makes the login page inaccessible to some users.
Form validation errors are programmatically associated with their fields
Trigger a validation error on a specific field. Inspect the HTML to verify the error message element is associated with the field using an aria-describedby attribute on the input pointing to the error message's id. Without this association, screen readers announce the error message separately from the field, making it unclear which field the error applies to.
Login doesn't depend on a cognitive function test (WCAG 2.2, 3.3.8 Accessible Authentication)
Verify users can sign in without memorising, transcribing or solving anything. Password managers and paste must work, and any CAPTCHA must offer an alternative that doesn't depend on a puzzle or memory test.
Focused elements aren't hidden by sticky headers or banners (WCAG 2.2, 2.4.11 Focus Not Obscured)
Tab through the login form with cookie banners and sticky headers visible. Verify the focused field or button is never fully covered.
BDD Test Cases for Login Page
Behavior Driven Development (BDD) scenarios bridge the communication gap between QA engineers, developers, and business stakeholders. Here are login scenarios expressed in Gherkin syntax:
Scenario: Successful login with valid credentials
Scenario: Account lockout after consecutive failures
Scenario: SSO login via identity provider
Scenario: Login page accessibility validation
How AI is Transforming Login Page Testing
Traditional login testing depends on hand-written test cases, brittle selectors and constant upkeep.
AI-native testing changes each of those.
AI Powered Test Generation
Virtuoso QA's Touchstone agents draft login tests from your existing specs, user stories and security policies, citing the source for each one. A named person approves every requirement before it's built.
Self Healing Test Maintenance
When field IDs, button text or CSS classes change, self-healing finds the element through other signals and updates the test. Every repair is logged for your team to review, so nothing changes without a record.
Natural Language Test Authoring
With Natural Language Programming, manual testers and analysts can write login tests in plain English, including steps that handle iFrames, Shadow DOM and API calls.
Cross Browser Validation at Scale
Login tests run in parallel across 2,000+ browser, device and OS combinations, confirming authentication works the same everywhere.
Composable Test Libraries for Authentication
Reusable authentication modules are configured for each application instead of rebuilt for every project.
Evidence for Every Authentication Release
Every run produces release evidence showing which requirement each login test covers and who approved it. When a security review asks how authentication was tested, the answer is already written down.
Best Practices for Writing Login Page Test Cases
Writing effective login test cases requires more than covering scenarios. It requires discipline in structure, clarity, and maintainability.
Start with risk based prioritization
Focus first on the test cases that protect against the highest impact failures: credential compromise, session hijacking, and authentication bypass. Security and functional tests take precedence over cosmetic UI checks.
Use structured test case IDs and naming conventions
Every test case should have a unique identifier, a descriptive title, clearly defined preconditions, step by step actions, and explicit expected results. This structure enables traceability, reporting, and efficient regression management.
Separate positive and negative test paths
Grouping test cases by intent (valid inputs versus invalid inputs) makes test suites easier to navigate, maintain, and extend as the application evolves.
Integrate API and UI tests for complete coverage
Testing only the login form misses backend vulnerabilities. Combine UI level authentication tests with direct API endpoint validation to ensure both layers are secure and functional.
Automate early and maintain continuously
Login functionality is exercised in every regression cycle. Automating these test cases provides consistent, repeatable validation with every code change and deployment.
Test across environments, not just browsers
Validate login behavior in development, staging, and production equivalent environments. Configuration differences between environments are a common source of authentication defects.
Tools for Creating and Automating Login Page Test Cases
The tools you choose determine how efficiently login tests are created, maintained, and scaled.
Selenium remains the most widely adopted open source framework for browser automation. It provides granular control but requires significant coding expertise and ongoing maintenance.
Cypress offers a developer friendly experience for modern JavaScript applications, with real time reloading and automatic waiting. It is limited to Chromium based browsers and Firefox.
Playwright supports cross browser testing with a modern API, including Chromium, Firefox, and WebKit. It handles modern web patterns like Shadow DOM effectively.
Virtuoso QA takes a different approach as an AI-native testing platform. Tests are written in plain English, repaired through reviewable self-healing, and run across 2,000+ browser and device combinations on a cloud grid. For enterprise teams testing login and SSO flows on business systems like SAP, Oracle, Salesforce and Dynamics 365, Virtuoso QA keeps tests stable through UI changes and produces release evidence for every run, so you can show exactly how authentication was tested.
Related Reads
Frequently Asked Questions
How many test cases are needed for a login page?
What are the most important login page test cases?
How do you test SSO login functionality?
Can AI automate login page test creation?
How do you test login page performance?
What accessibility standards apply to login pages?
