How to Write Test Cases for Login Page

A login defect can lock out valid users, expose account information, or leave an authenticated session open after logout. These issues often sit outside the basic valid and invalid credential checks, so they are easy to miss until users encounter them in production.

Login page test cases should cover the complete authentication flow, including field validation, account lockout, password recovery, MFA, cookies, session expiry, mobile behavior, security, and performance.

The test cases below show what to verify and what result you should expect in each scenario.

What are Test Cases for the Login Page?

Login page test cases are documented checks used to verify how the application handles authentication under specific conditions. Each test case defines the starting state, the input, the action, and the expected result.

For example, it may verify whether a locked user is denied access, whether an expired session redirects to login, or whether invalid credentials return the correct error without revealing account details.

These test cases should cover more than the username and password fields. You also need to verify account rules, MFA, password recovery, cookies, session handling, error messages, and access to protected pages after login or logout. This helps you test the complete authentication flow instead of treating login as a single form submission.

Types of Test Cases for Login Page

Login testing is easier to plan when test cases are grouped by the risk they address. Some test cases verify authentication rules. Others focus on the interface, security controls, response time, or failure handling. These groups can overlap, but each one should have a clear purpose.

1. Functional Test Cases

Functional testing verifies whether the login flow follows the application’s defined requirements. They check what the system does after a specific user action.

For example, you may verify that a registered user can log in with valid credentials, an unregistered user cannot access the application, and a user with MFA enabled is taken to the verification step. Functional testing also covers password recovery, social login, account lockout, logout, and redirection after successful authentication.

Use functional test cases when you need to validate a business rule or an expected authentication flow. Do not use them as a substitute for checking response time, visual layout, or security weaknesses.

2. Non-Functional Test Cases

Non-functional testing verifies how well the login flow works rather than whether a particular feature works. They cover areas such as usability, accessibility, reliability, scalability, and compatibility.

For example, you may check whether the page remains usable with keyboard-only navigation, whether screen readers announce field labels correctly, or whether authentication remains available during a temporary dependency failure. Cross-browser behavior may also be covered when the focus is consistency rather than a specific login rule.

Use non-functional test cases when the requirement describes a quality attribute. Avoid using this category as a catch-all for tests that already belong to a more specific group such as security or performance.

3. UI Test Cases

UI testing focuses on what the user sees and interacts with on the login page. They verify field labels, buttons, links, spacing, validation messages, focus states, password masking, and responsive behavior.

A UI test may confirm that the login button remains visible when the mobile keyboard opens or that an error message appears next to the correct field. It can also verify that disabled, loading, and active states match the approved design.

Use UI test cases when a defect can be identified through the visible interface or user interaction. Avoid using them to confirm backend authentication rules unless the interface is only one part of a broader functional test.

4. Security Test Cases

Security test cases verify whether the login flow prevents unauthorized access and protects authentication data. They cover input handling, credential storage, transport security, session management, account enumeration, brute-force protection, and access control.

For example, you may verify that the application does not reveal whether a username exists, session cookies use the required security attributes, and protected pages cannot be opened after logout. Security testing should also confirm that authentication controls are enforced on the server. Hiding a button or blocking an action in the browser is not sufficient.

Use security test cases when the failure could expose data, weaken access control, or allow an attacker to misuse the authentication flow. Avoid treating every invalid-input test as a security test. The test should target a defined threat or security control.

5. Negative Test Cases

Negative testing checks how the login flow handles invalid, incomplete, unexpected, or disallowed input. Their purpose is to confirm that the system rejects the action safely and gives the user an appropriate response.

Examples include submitting empty fields, entering an invalid email format, using an expired OTP, attempting login with a locked account, or sending input that exceeds the accepted length. These tests should verify both the rejection and the resulting state. A failed login should not create a session or expose protected data.

Use negative test cases when you need to test validation rules, failure paths, and boundary conditions. Avoid writing random invalid inputs without linking them to a requirement, risk, or known input constraint.

6. Performance Test Cases

Performance testing measures how the login system behaves under expected and extreme workloads. They assess response time, throughput, resource use, error rate, and recovery after load is reduced.

A performance test may measure authentication latency during peak traffic or check whether rate limiting continues to work when many login attempts arrive at once. The workload should reflect the architecture. A login flow that calls an identity provider, risk engine, and MFA service may fail differently from a login flow handled by one application server.

Use performance test cases when the team has measurable targets for latency, concurrency, throughput, or availability. Avoid using a single browser timer as proof of backend performance. Network conditions, test data, server load, and external dependencies must be controlled or recorded.

Comparison of Login Page Test Case Types

The table below shows where each test type fits and where it should not be used as a substitute for another form of testing.

Characteristics and Components of a Login Page

Before diving into the test cases, it’s essential to understand the components of a typical login page. A standard login page consists of:

• Username/Email Input Field: Where users input their credentials.
• Password Input Field: A secure field that masks the user’s password.
• Submit Button: Triggers the authentication process.
• Remember Me Checkbox: An option to retain user credentials for future logins.
• Forgot Password Link: Allows users to reset their password.
• Social Login Buttons: Options to log in using third-party services like Google or Facebook.

Each component needs to be tested meticulously to ensure they work as intended under all circumstances.

Functional Test Cases for Login Page

Functional test cases verify that all the elements of the login page work as expected. These are widely categorized into positive and negative scenarios.

Positive Test Cases

The following positive test cases validate the system’s ability to authenticate users effectively through standard login methods.

• Valid Login with Correct Credentials: Enter a valid username and password and click the login button. The user should be successfully logged in and then be redirected to the dashboard.
• Case Sensitivity of Username and Password: Test the login with different cases (uppercase/lowercase) for the username and password. Login should only succeed if the exact case is used.
• Valid Login with Social Media: Log in using a social media account (like Google). The user should be logged in successfully using social media credentials.

Negative Test Cases

These are some negative sample test cases for a login page

• Login with Invalid Credentials: Enter an incorrect username or password and attempt to log in. The system should deny access and display an error message.
• Login with Empty Fields: Try to log in without entering any credentials. The system should prompt the user to fill in the required fields.
• Login with SQL Injection: Attempt to log in by entering an SQL query in the username or password field to manipulate the database query executed by the application. The system should reject the input and not execute the SQL query.
• Locked Account After Multiple Failed Attempts: Enter incorrect credentials multiple times to test account locking mechanisms. After a set number of failed attempts, the account should be locked, and the user should receive a notification.

Non-Functional Test Cases for Login Page

A login flow can return the correct result and still be unsafe or difficult to use. Non-functional test cases check the qualities around authentication, such as security, accessibility, reliability, and usability.

The expected result should be measurable wherever possible. Instead of stating that the page should be “user-friendly,” define what must happen. For example, every control should be reachable through the keyboard, error messages should be announced by a screen reader, and a failed request should not leave the form in a permanent loading state.

1. Security Test Cases

Security test cases verify that the login flow protects credentials, sessions, and restricted application areas. These checks should cover both the browser behavior and the server response. A control implemented only in the interface can often be bypassed by sending a request directly to the server.

Important security test cases include:

• Prevent account enumeration: Submit an existing username and an unknown username with incorrect passwords. The responses should not reveal which account exists through the message, status code, or noticeable timing difference.
• Protect credentials in transit: Confirm that the login page and authentication requests use HTTPS. Credentials must not appear in the URL, browser history, application logs, or analytics events.
• Handle repeated failures: Verify that rate limits, progressive delays, CAPTCHA, or account protection rules activate after the configured number of failed attempts.
• Secure the authenticated session: Check that session cookies use the required Secure, HttpOnly, and SameSite attributes. A new session identifier should be issued after successful authentication.
• Invalidate sessions correctly: After logout, confirm that the old session token cannot open protected pages or call authenticated APIs. The browser back button should not restore usable authenticated content.
• Enforce authorization on the server: Attempt to open protected routes without a valid session. The server should deny access even when the request is created outside the application interface.
• Protect password recovery and MFA: Reset links and OTPs should expire, allow limited attempts, and become unusable after successful verification.
• Handle malicious input safely: Submit unexpected characters and oversized values to the login fields. The application should reject or safely process them without returning database errors, stack traces, or internal details.

A failed security test should not be judged only by what appears on the page. Review network responses, cookies, redirects, server logs, and session state to confirm whether the control actually worked.

2. Usability Test Cases

Usability testing verifies whether users can understand and complete the login flow without unnecessary confusion. This includes users who rely on a keyboard, screen reader, password manager, zoom, or other assistive technology.

Useful usability test cases include:

• Keyboard navigation: Confirm that users can reach the username field, password field, login button, recovery link, and other controls in a logical order.
• Visible focus: Check that the focused control is easy to identify and that focus does not disappear behind custom styling.
• Accessible labels: Verify that input fields have programmatic labels and that screen readers announce the field name, requirement, and error state correctly.

• Clear validation messages: Error messages should explain what the user can correct without exposing sensitive account information. Focus should move to or clearly identify the first invalid field.
• Password field behavior: Confirm that masking works correctly and that show-password controls are accessible, clearly labeled, and do not change the entered value.
• Password manager support: Test whether browsers and password managers can identify and fill the username and password fields without breaking validation.
• Recovery path: Make sure users can find the forgotten-password or account-recovery option without searching through unrelated content.
• Loading and retry states: The login button should not create duplicate requests when clicked repeatedly. If authentication fails because of a network issue, the user should be able to retry without reloading the entire page.
• Zoom and text resizing: Check the page at higher browser zoom levels. Fields, instructions, and error messages should remain readable without overlapping or becoming inaccessible.

These tests should use defined acceptance criteria. Terms such as “easy to use” or “accessible” are too broad to produce a reliable result. State the exact interaction, user condition, and expected behavior for each test case.

BDD Test Cases for Login Page

BDD (Behavior-Driven Development) test cases describe login behavior in terms that testers, developers, product managers, and other stakeholders can review together. They usually follow the Given, When, Then structure:

• Given defines the user’s starting state.
• When describes the action the user takes.
• Then states the result the application must produce.

A good BDD scenario should test one behavior at a time. It should also include enough context to explain why the result changes. For example, “invalid login” is too broad because the expected behavior may differ for an unknown account, a wrong password, a locked user, or an expired password.

1. Successful Login

Given: A registered user has an active account and valid credentials.
When: The user submits the correct username and password.
Then: The application should create an authenticated session and redirect the user to the expected page.

The scenario should define where the user is redirected. It should also verify that protected pages become accessible only after the session is created.

2. Login with Incorrect Credentials

Given: A registered user has an active account.
When: The user submits an incorrect password.
Then: The application should reject the login attempt and display the approved error message.

The test should also confirm that no authenticated session is created. The response should not reveal whether the username or email address exists unless the product explicitly allows that behavior.

3. Login with a Locked Account

Given: A user account has been locked after repeated failed login attempts.
When: The user submits valid credentials.
Then: The application should deny access and show the account recovery or support instructions defined in the requirements.

This scenario is different from an incorrect-password test. The credentials may be valid, but the account state prevents authentication.

4. Password Recovery

Given: A registered user cannot remember the account password.
When: The user requests a password reset using the registered email address.
Then: The application should start the recovery process without exposing sensitive account information.

A separate scenario should verify the reset link or OTP. The expected result should define its expiry time, allowed attempts, and behavior after successful use.

5. Login with MFA Enabled

Given: A registered user has MFA enabled and submits valid credentials.
When: The first authentication step succeeds.
Then: The application should request the configured second factor before granting access.

Further scenarios should cover an invalid OTP, an expired OTP, repeated failures, backup codes, and cancellation of the MFA step.

6. Session Expiry

Given: A user has logged in and the authenticated session has expired.
When: The user tries to open a protected page or perform an authenticated action.
Then: The application should deny the request and redirect the user to the login page.

The scenario should also confirm that the application does not display protected data from an expired session.

BDD scenarios work best when they describe behavior rather than page-level actions. Avoid steps such as “click the blue button” unless the button itself is part of the requirement. Describe what the user is trying to do and what the system must enforce. This keeps the scenario useful even when the interface changes.

UI Test Cases for Login Page

UI testing ensures the login page meets design specifications and provides a positive user experience.

Visual Consistency

Verify that the login page appears consistently across different browsers and devices. The layout, fonts, and colors should match the design guidelines.

Error Message Display

Make sure that error messages are correctly displayed when a user enters invalid credentials. The error messages should be clear, concise, and prominently displayed.

Responsive Design

Test the login page on various screen sizes to ensure it is fully responsive. The page should adapt smoothly to different screen sizes without any layout issues.

Performance Test Cases for Login Page

A login page may load quickly while the authentication request behind it is slow or unstable. The browser only displays the form. The actual login flow may depend on a user database, identity provider, MFA service, fraud checks, session store, and several internal APIs. Performance testing should measure the complete authentication path, not just page load time.

Useful performance test cases include the following:

1. Login Response Time Under Normal Load

Send login requests at the traffic level expected during regular use.

Verify:

• Authentication response time remains within the defined limit.
• Valid users receive a session without unexpected delays.
• Invalid credentials return a response within a similar time range.
• CPU, memory, database connections, and identity-service calls remain stable.

Do not rely only on average response time. Check median and percentile values such as p95 or p99 because a small group of very slow requests can affect real users without changing the average significantly.

2. Concurrent Login Test

Simulate many users attempting to log in at the same time. This often happens at the start of a workday, after a system outage, or when an event opens for registration.

Verify:

• The system handles the expected number of concurrent authentication requests.
• Successful logins do not create duplicate or missing sessions.
• Database and connection pools do not become exhausted.
• Error rates remain within the agreed limit.
• Queued requests recover after traffic returns to normal.

Each virtual user should use separate credentials where possible. Reusing one account can trigger account locks, session replacement, or rate limits that distort the result.

3. Spike Test

Increase login traffic sharply within a short period instead of raising it gradually.

Verify:

• The authentication service does not crash during the spike.
• Autoscaling or traffic controls activate as expected.
• Response times recover after the spike ends.
• The system does not leave incomplete sessions or stuck authentication requests.

A spike test is useful when login traffic can change suddenly. It should not replace normal load testing because the two tests answer different questions.

4. Stress Test

Stress testing involves continuing increasing the workload until the system reaches or exceeds its supported capacity.

Verify:

• The system fails in a controlled manner.
• Users receive appropriate errors instead of timeouts or broken pages.
• Security controls remain active under heavy load.
• The service recovers without manual cleanup after traffic is reduced.
• No data corruption or incorrect session assignment occurs.

The goal is not only to find the breaking point. You also need to understand how the login service behaves near that limit and whether it recovers correctly.

5. Sustained Load Test

Run login traffic for an extended period at a realistic level.

Verify:

• Memory and resource use do not continue increasing.
• Session stores and database connections remain stable.
• Response times do not degrade over time.
• Logs, audit records, and queued events do not create a growing backlog.
• Token generation and expiration continue to work correctly.

This test can reveal memory leaks, connection leaks, and cleanup problems that a short load test may miss.

6. Dependency Delay Test

Introduce latency or partial failure in services used during login, such as the database, identity provider, MFA service, or risk engine.

Verify:

• The application applies the configured timeout.
• Users do not remain in an endless loading state.
• Retries do not multiply traffic and overload the dependency.
• Failed requests do not create partial sessions.
• The system returns a recoverable error when the dependency is unavailable.

Record dependency response times separately from total login time. This helps the team determine whether delays originate in the application or an external service.

7. Failed Login Load Test

Send a controlled volume of invalid login attempts.

Verify:

• Rate limiting and account protection rules continue to work under load.
• Invalid requests do not consume significantly more resources than expected.
• Error messages do not reveal account existence.
• Valid users can still authenticate while invalid traffic is being processed.
• Logging and monitoring systems can handle the additional security events.

Run this test only in an approved environment with dedicated accounts and controlled data. Unrestricted failed attempts can lock users, trigger security alerts, or affect shared authentication services.

A complete performance test result should include the workload model, test data, environment configuration, response-time percentiles, throughput, error rate, resource use, and dependency timings. Without that context, a statement such as “1,000 users logged in within two seconds” is difficult to reproduce or use for capacity decisions.

Login Page Test Cases – CAPTCHA & Cookies

Here are the login page test cases, specially focused on testing CAPTCHA and Cookies:

Test Cases for CAPTCHA

Here are the test cases for Captcha:

1. Verify CAPTCHA appears after multiple failed login attempts

Expected: CAPTCHA should be triggered after predefined failed login attempts (e.g., 3).

2. Verify login with correct credentials, but wrong CAPTCHA

Expected: Login should fail with an appropriate error message.

3. Verify CAPTCHA refresh functionality

Expected: A new CAPTCHA image or code should be reloaded after clicking the refresh icon

4. Verify login is successful when CAPTCHA is entered correctly

Expected: The user will be logged in if the credentials and CAPTCHA are valid.

Test Cases for Cookies

Cookies often control whether a user stays signed in, how the application recognizes an authenticated session, and what happens after logout or session expiry. Testing only whether a cookie exists is not enough.

1. Verify the Session Cookie After Login

Log in with valid credentials and inspect the cookies created by the application.

Expected result: The application should create the required authentication or session cookie only after successful login. The cookie value should not expose the username, password, access rights, or other sensitive information in readable form.

2. Verify the “Remember Me” Behavior

Log in after selecting the “Remember Me” option. Close the browser, reopen it, and return to the application.

Expected result: The user should remain signed in only for the period defined by the product requirements. The application should store a persistent session identifier or token, not the user’s password.

Repeat the test without selecting “Remember Me.” In that case, the session should end according to the expected browser-session behavior.

3. Verify Cookie Security Attributes

Inspect the authentication cookie after login.

Expected result: Cookies that carry session or authentication data should use the required security attributes:

• Secure prevents the browser from sending the cookie over an unencrypted connection.
• HttpOnly prevents client-side JavaScript from reading the cookie.
• SameSite controls whether the cookie is sent with cross-site requests.

The expected SameSite value depends on the application’s authentication flow. For example, some third-party login integrations may require different handling from a standard username and password flow.

4. Verify Logout Invalidates the Cookie

Log in, capture the active session cookie, and then log out.

Expected result: The browser should remove or expire the relevant cookie. More importantly, the server should reject the old cookie if it is reused. Deleting the cookie only in the browser is not sufficient if the session remains valid on the server.

5. Verify Expired Cookies

Allow the session cookie to expire or replace its expiry value with an invalid one in a controlled test environment.

Expected result: The user should be redirected to the login page when attempting to open a protected page. The application should not display cached protected data or create a new authenticated session without verification.

6. Verify Behavior After Clearing Cookies

Log in successfully, clear the application’s cookies, and then open a protected page.

Expected result: The application should treat the user as unauthenticated and redirect them to the login page. Any authenticated API request should also fail with the expected authorization response.

Mobile Responsiveness Test Cases for Login Page

Mobile responsiveness testing checks whether the web login page remains usable when the viewport, browser controls, keyboard, zoom level, or device orientation changes. The goal is not only to confirm that the page fits on a smaller screen.

Users should be able to enter credentials, read validation messages, open recovery links, and submit the form without hidden or overlapping controls.

These tests apply to login pages opened in mobile browsers.

1. Verify the Login Layout Across Mobile Viewports

Open the login page at the supported mobile viewport sizes, including the smallest width defined in the requirements.

Expected result: Username and password fields, labels, buttons, recovery links, and supporting text should remain visible and aligned. The page should not introduce unintended horizontal scrolling.

Do not test only common device presets. Include widths near responsive breakpoints because layout issues often appear just before or after the design switches between breakpoints.

2. Verify Behavior When the Mobile Keyboard Opens

Tap the username and password fields to open the on-screen keyboard.

Expected result: The focused field and login button should remain reachable. The keyboard should not permanently cover the active field, error message, or submit button. Users should be able to scroll the page when required.

Repeat the test with validation messages displayed because added content may push the submit button below the visible area.

3. Verify Input Types and Mobile Keyboards

Tap each login field and inspect the keyboard shown by the mobile browser.

Expected result: An email field should use the appropriate input type so the keyboard provides useful characters such as @. The password field should mask the value and avoid unwanted spelling correction or automatic capitalization.

Incorrect input types may not block login, but they make credential entry slower and increase typing errors.

4. Verify Touch Target Size and Spacing

Tap the login button, password visibility control, “Remember Me” option, recovery link, and social login buttons.

Expected result: Each control should respond to a normal tap without requiring precise selection. Adjacent controls should have enough spacing to prevent accidental activation.

The test should use real touch input where possible. A desktop mouse does not reproduce finger size, tap accuracy, or mobile scrolling behavior.

5. Verify Portrait and Landscape Orientation

Open the login page in portrait mode, enter partial credentials, and rotate the device to landscape mode. Repeat the test by rotating back to portrait.

Expected result: The layout should adjust without overlapping or hiding controls. Entered values, validation state, and focus should remain intact unless the requirements define otherwise.

The page should not reload or clear the form only because the orientation changed.

6. Verify Error Messages on Small Screens

Submit empty, invalid, or incomplete credentials on a narrow viewport.

Expected result: Error messages should appear near the relevant field and remain readable without overlapping other content. The page should move focus to the first invalid field or make the error easy to locate.

Long translated messages should also be tested because they may occupy several lines and change the layout.

7.  Verify Zoom and Text Scaling

Increase browser zoom or the device text size to the supported accessibility level.

Expected result: Labels, fields, buttons, and error messages should remain readable and usable. Text should not be clipped, and controls should not overlap when content expands.

A layout that works only at the default text size is not reliably responsive.

8. Verify Autofill and Password Manager Behavior

Use browser autofill or a password manager to populate the login fields.

Expected result: Values should appear in the correct fields and remain visible to the application’s validation logic. Autofill should not create unreadable text, unexpected background styling, or a disabled login button.

Test saved credentials as well as manually selected credentials because mobile browsers may handle them differently.

9. Verify Mobile Browser Compatibility

Run the login flow on the supported mobile browsers and operating system versions to verify mobile browser compatibility.

Expected result: The page should render correctly and support credential entry, validation, password visibility, recovery links, and form submission consistently.

Testing only resized desktop Chrome is not enough. Mobile Safari and Android browsers may handle viewport height, autofill, keyboard behavior, and browser toolbars differently.

10. Verify Browser Toolbar and Viewport Height Changes

Scroll the page so the mobile browser’s address bar or navigation controls collapse and reappear.

Expected result: The login form should not jump, become clipped, or move the focused field outside the visible area. Full-height containers should adjust correctly when the available viewport height changes.

This test is important for layouts built with viewport-based CSS units because mobile browser controls can change the usable height while the page is open.

Test Cases For Login Page on Mobile Application

Mobile application login testing should focus on device and operating system behavior that a mobile browser test cannot cover. The following test cases avoid repeating standard credential, layout, cookie, and network checks.

1. Verify Biometric Login

Enable fingerprint or face authentication for an existing account, then close and reopen the application.

Expected result: The application should authenticate the user only after successful biometric verification. After repeated failures or biometric cancellation, it should provide the approved fallback method, such as a password or device PIN.

2. Verify Login After Biometric Data Changes

Register biometric login, then add or remove a fingerprint or face profile through the device settings.

Expected result: The application should follow its security policy for changed biometric data. Security-sensitive applications may revoke biometric login and require the user to authenticate again with full credentials.

3. Verify Secure Credential Storage

Log in and inspect the application’s local storage using an approved test environment.

Expected result: Passwords, access tokens, refresh tokens, and other authentication data should not appear in plain text. Sensitive values should use platform-protected storage such as Android Keystore or iOS Keychain.

4. Verify App Backgrounding During Login

Start the login process and move the application to the background before authentication finishes. Reopen it after a short and an extended interval.

Expected result: The application should resume from a valid state or safely restart authentication. Sensitive values should not appear in the recent-apps preview, and incomplete authentication should not create a usable session.

5. Verify Login After an Application Update

Log in on an older application version, install the supported update, and open the updated application.

Expected result: The application should handle stored authentication data according to the release requirements. A compatible session may continue, while a security-related update may require fresh authentication. The update should not corrupt stored credentials or leave the user in a login loop.

6. Verify Login After Reinstallation

Log in, uninstall the application, reinstall it, and launch it again.

Expected result: The application should not restore an authenticated state from unprotected local data. Any restored login state should come only from an explicitly supported and secure backup mechanism.

7. Verify Authentication Redirects Between Applications

Start an SSO or external identity-provider login that opens another application or system authentication screen.

Expected result: After successful authentication, the user should return to the correct application and screen. The callback should be accepted only by the intended application, and canceled or invalid callbacks should not grant access.

8. Verify Login on a Compromised Device

Run the application on a rooted Android device, jailbroken iOS device, emulator, or device with debugging enabled where this is relevant to the product’s risk model.

Expected result: The application should apply the defined policy. It may block login, restrict sensitive features, request additional verification, or record the device risk. The behavior should remain consistent and should not expose internal detection details.

Gmail Login Page Test Cases

The Gmail login page is the main entry point for users using their Google accounts. Ensuring a smooth, secure, and user-friendly process for accessing the Gmail login page is essential for a positive user experience. Below are key sample test cases for the Gmail login page:

Functional Test Cases

• Verify login with valid Gmail ID and password.
• Verify login with invalid credentials (wrong ID/password).
• Verify behavior when fields are left blank.
• Check “Next” button functionality after entering the email.
• Validate the “Forgot email?” and “Forgot password?” links.
• Verify login with Google account using MFA (OTP or app-based).

Security Test Cases

• Ensure password is masked while typing.
• Verify account lockout after multiple failed attempts.
• Check HTTPS is used for secure data transfer.
• Verify redirection to 2-step verification when enabled.

Session & Cookies

• Verify “Stay signed in” or “Remember me” functionality.
• Test logout and session expiry behavior.
• Ensure login fails after clearing browser cookies.

How to Test SQL Injection on a Login Page?

Testing SQL Injection on a login page includes testing the application’s vulnerability to SQL injection attacks, which happen when untrusted data is improperly included in an SQL query. Here’s how you Test SQL Injection on a Login Page:

1. Detect the input fields used for username/email and password.
2. Test the input fields by entering standard SQL injection payloads in the username and password fields like — ‘ OR 1=1 –, ‘ OR ‘a’=’a, ‘ OR ‘1’=’1′ –, ‘ AND 1=1 – , admin’ — (for username field), admin’ # (for username field).
3. Test if entering a single quote (‘) or double quote (“) in the username or password field triggers an error (e.g., syntax errors) in the application. Example input: ‘ OR 1=1–
4. After submitting the payloads, check if any database error messages are displayed. These messages can expose vulnerabilities.
5. Test if entering a payload like ‘ OR 1=1 — bypasses the login process and grants unauthorized access. A successful SQL injection should log you in without valid credentials.
6. Test more advanced SQL injection variants like UNION-based injection, time-based blind SQL injection, or error-based injection. Example: ‘ UNION SELECT null, username, password FROM users –
7. Check if the system implements any security mechanisms, such as account lockout after multiple failed login attempts, to prevent SQL injection abuse.
8. Verify that the system sanitizes inputs properly by rejecting invalid or malicious input.

Best Practices for Writing Test Cases for Login Page

Login test cases become difficult to maintain when they are written as long click-by-click scripts or when one test tries to verify several authentication rules at once. A useful test case should make the user state, test data, action, and expected system behavior clear enough that another tester can run it without guessing.

The following practices help keep login test cases precise and useful as the authentication flow changes.

1. Define the User and Account State

Do not begin every test with only “open the login page.” Authentication behavior often depends on the state of the account.

State whether the user is:

• Registered or unregistered
• Active, locked, disabled, or suspended
• Using an expired password
• Enrolled in MFA
• Already signed in on another device
• Subject to a specific role or organization policy

For example, a valid password should not produce the same result for an active account and a locked account. Without the account state, the expected result becomes ambiguous.

2. Keep One Main Behavior Per Test Case

A single test case should have one clear reason to pass or fail. Avoid combining valid login, logout, session expiry, and password recovery into one long flow.

Separate test cases make failures easier to diagnose. They also allow you to rerun only the affected behavior after a change.

For example:

• Verify login with valid credentials
• Verify logout invalidates the current session
• Verify an expired session cannot access a protected page

These checks may use the same account, but they validate different rules.

3. Write Expected Results for Every Important Step

Do not leave all verification until the final step. Authentication failures can happen before the user reaches the expected page.

A complete test should verify intermediate behavior such as:

• Whether the login button enters a loading state
• Whether duplicate submissions are blocked
• Whether an MFA challenge appears
• Whether the session is created only after verification
• Whether the correct page opens after authentication

Writing intermediate results helps identify where the flow broke instead of recording only that “login failed.”

4. Verify Backend State, Not Only the Visible Message

A correct message does not prove that the authentication control worked. The page may show “logged out” while the old session token still accesses protected APIs.

Where relevant, include checks for:

• Session creation and invalidation
• Cookie or token state
• Protected API responses
• Account lockout counters
• Audit events
• Redirect behavior
• Access to restricted routes

The expected result should describe both the visible response and the security state behind it.

5. Use Controlled and Traceable Test Data

Create test accounts for specific conditions instead of repeatedly changing one shared account. Shared data can cause false failures when tests run in parallel or when another tester changes the same user state.

Use separate accounts for cases such as:

• Active user
• Locked user
• MFA-enabled user
• Expired-password user
• Disabled user
• User with multiple active sessions

Record how each account is prepared and reset. Test data should be reusable without depending on the execution order of other test cases.

6. Cover Boundaries Around Authentication Rules

Many login defects appear at the edge of a rule rather than in its normal path.

When the requirement defines a limit, test values immediately before, at, and after that limit. Examples include:

• Password length limits
• Maximum failed attempts
• OTP expiry time
• Session timeout
• Resend delay
• Rate-limit threshold
• Remember Me duration

If an account locks after five failures, test the fourth, fifth, and sixth attempts. Checking only “several failed attempts” does not confirm the exact rule.

7. Avoid Hard-Coding Details That Change Often

Test cases should describe required behavior without tying every step to unstable interface details.

For example, write “submit the login form” instead of “click the blue button in the lower-right corner,” unless the button’s appearance or position is what you are testing.

You should still name controls clearly, but avoid references to colors, coordinates, temporary labels, or layout positions that do not affect the requirement. This reduces maintenance when the interface changes.

Conclusion

A reliable login test suite checks more than whether valid credentials grant access. It must verify account states, validation rules, MFA, recovery, sessions, cookies, security controls, performance, and behavior across browsers and mobile devices. The expected result should confirm both what the user sees and what happens behind the interface.

Build each test around a clear risk or requirement. Use controlled test accounts, test boundaries around limits, and verify server-side behavior when sessions or access controls are involved. Review the suite whenever authentication policies, identity providers, or recovery flows change so outdated assumptions do not leave gaps in coverage.