How to Write Test Cases for the Login Page: A Step-by-Step Guide

How to Write Test Cases for the Login Page: A Step-by-Step Guide

Have you ever paused at a login screen and wondered, “How can I be sure this works smoothly, securely, and for everyone?”. Testing a login page is like checking every lock, hinge, and peephole on a door: you want to let in the right people smoothly, keep out intruders, and make sure the door never jams. Whether you’re a new QA engineer, a developer wearing the tester’s hat, or a product lead who wants to nail quality from day one, testing your login page well is vital.

In this tutorial, you’ll learn how to create clear, thorough test cases for the login page — both detailed and high-level — that make your login rock-solid without making your head spin. By the end of our journey, you’ll cover all your questions from “Which tests should I automate first?” to “Can it handle 1,000 users at once?”.

Let’s roll in!

Overview

In this article, you’ll discover:

• Why login pages need extra care and what happens when they fail;
• Core functional test case types and non-functional checks: UI/UX, security, performance, plus CAPTCHAs, cookies, mobile, and Gmail-specific flows;
• Numerous practical step-by-step examples alongside concise test scenario checklists.

Functional Test Cases for Login Page

Functional tests check the “does it work?” aspects of your login page — valid inputs, invalid inputs, edge flows, and core behaviors. Think of these as first-aid checks: basic but essential. These functional test cases and non-functional test cases for login ensure the core path is solid.

Positive Test Cases

These ensure the login flow succeeds under the right conditions.

Example 1. Log in with Valid Credentials

Steps:

• Open the login page.
• Enter a valid username and password.
• Click Login or press Enter.
• Verify redirection to the user dashboard.
• Confirm that the user’s name or profile icon appears, and a session cookie is set.

Example 2. Log in Using the Enter Key

• On the login page, input valid credentials.
• Hit Enter instead of clicking.
• Check you’re logged in just as if you’d clicked Login.

Example 3. Log in with “Remember Me” Selected

• Open the login page.
• Enter valid credentials and check Remember Me.
• Log in, then close and reopen the browser.
• Confirm you remain logged in (session persists).

Some more examples:

• Case Sensitivity of Credentials: Alter uppercase/lowercase in username and/or password. Expect success only if the casing matches exactly.
• Social Media Login: Use “Login with Google” or similar. Verify successful redirection and account linkage.
• Simultaneous Valid Logins: Log in from two devices (e.g., desktop and mobile). Check whether the system allows both sessions or alerts you.
• Post-Activation Login: Complete email verification after signup. Attempt login immediately. Expect access without delay.
• Username or Email Login: Use either the username or registered email interchangeably. Both should grant access if credentials match.

Negative Test Cases

These verify that the system rejects bad inputs and handles errors gracefully. These security test case checks also guard against malicious use.

Example 1. Invalid Username & Password

• Open the login page.
• Enter an unregistered username and a random password.
• Click Login.
• Verify an error: “Invalid username or password”.

Example 2. Blank Fields Submission

• Leave both fields empty.
• Click Login.
• Expect error: “Please enter username and password”.

Example 3. Expired or Locked Account

• Use credentials for an account that’s expired/locked.
• Click Login.
• Confirm login is blocked and the appropriate message is shown.

Some more examples:

• Valid Username, Invalid Password: Correct username + wrong password. Expect failure and a non-specific error (“Invalid credentials”).
• Invalid Username, Valid Password: Wrong username + password of a real account. Verify login fails without hinting which field is wrong.
• SQL Injection Attempt: Input payloads like ’ OR 1=1 — . Ensure no unauthorized access or database errors.
• Account Lockout After Multiple Failures: Fail login 3–5 times in a row. Verify account locks or delays further attempts.
• XSS Payload in Input: Try alert(’X’) in username. Ensure no script execution or reflected output.

UI/UX Test Cases

Good UI/UX tests ask: “Is this comfortable, clear, and accessible?”. A login page with confusing labels or hidden fields is like a door you can’t see — you’ll drive users away. These UI test login test cases cover visual and interactive quality.

Responsive Design

Check that your login adapts to all screen sizes and orientations.

Steps:

• Open the login page on desktop (resize window to half-width and full-screen)/tablet (portrait and landscape)/mobile phone (portrait and landscape).
• Rotate devices or emulate orientation changes.
• Confirm all fields, buttons, and text remain visible and usable.
• Test extreme sizes (large monitors, small phones).
• Use browser dev tools or device labs to verify layouts on real devices.

Error Message Display

Error feedback should be clear, close to the field, and accessible.

Steps:

• Trigger errors by: Submitting blank fields and entering invalid credentials.
• Observe: Message content (friendly, non-technical)/Placement (adjacent to the field)/Color contrast (WCAG compliance).
• After an error, ensure only password fields are cleared (if policy), while other inputs persist.

Accessibility

These tests check whether everyone can use your login, including keyboard-only and screen-reader users?

Steps:

• Navigate using only the keyboard (Tab, Shift+Tab, Enter).
• Confirm focus order is logical and visible (outline or highlight).
• Check ARIA labels for input fields and buttons.
• Run automated tools (Axe, Lighthouse) to catch WCAG issues.
• Test with screen readers (NVDA, VoiceOver): do labels, instructions, and errors read naturally?

Field and Label Visibility

Labels must be clear, consistent, and always visible.

Steps:

• Verify static labels (not just placeholders) describe each field.
• Confirm contrast between text and background meets standards.
• Ensure spacing prevents overlap, even on small screens.
• Check that required fields are marked (asterisks) with explanations.

Need help with testing your app?

Contact us and let’s discuss!

Security Test Cases

Security tests are your lock and alarm system, ensuring data stays private and attackers stay out. We’ll break this into focused subsections, covering test sql injection and more.

HTTPS Enforcement

Steps:

• Attempt http://yourapp.com/login.
• Confirm automatic redirect to https://.
• In DevTools → Network tab, verify all requests (form posts, assets) using HTTPS.
• Try intercepting the request (e.g., with a proxy) — no data should leak.

Cross-Site Scripting (XSS) Testing

• Enter common XSS payloads in inputs (e.g., alert(1)).
• Submit and check that no script executes or appears in responses.
• Verify HTTP headers include Content-Security-Policy and XSS protection.

Account Lockout Policies

• Fail login repeatedly (3–5 times).
• Check if the account is locked or delayed.
• Ensure error messages don’t reveal which field is incorrect.
• Review logs or alerts for suspicious behavior.

Remember Me Security

• Log in with Remember Me checked.
• Close/reopen browser; verify session persists only on the same device.
• Inspect cookies: should be HttpOnly, Secure, and properly scoped.
• Log out; confirm cookies are deleted or invalidated.

How to Test SQL Injection on the Login Page

Improper input handling can let attackers slip through SQL doorways. Here are eight SQL injection on a login page test scenarios you can adapt into test cases:

• Input ’ OR 1=1 — in username; any password. Expect no unauthorized login.
• Use ’ OR ’a’=’a in username; random password. Verify denial.
• Try admin’ — username with blank password. Check for safe failure.
• Enter a lone quote (’) in username or password. Ensure no syntax error leaks or crashes.
• Test union-based payloads: ’ UNION SELECT null, password FROM users — . Look for info leaks.
• Time-based blind test: admin’ OR IF(1=1,SLEEP(5),0) — . Watch for delayed responses.
• Flood with SQLi attempts to trigger account lockout or alerting.
• Verify that valid login queries never expose raw error messages or database structure.

Performance and Load Test Cases

Stress-testing your login under load reveals how your “door” holds up when the crowd rushes in. These performance test scenarios help ensure reliability:

• Simulate 50, 500, and 1,000 concurrent logins; monitor success rate.
• Measure response times under normal vs. peak load; aim for <2s in 95% cases.
• Create traffic spikes; check for queuing or timeouts.
• Monitor CPU/RAM under load — does the service scale or stall?
• Observe the failed login rate if the database slows or disconnects.
• Test on throttled networks (3G, 2G); verify user-friendly timeouts.
• Quantify throughput (logins/min).
• Ensure graceful degradation: if the backend is under heavy load, display clear messages rather than errors.

CAPTCHA Test Cases

CAPTCHA’s fend off bots — let’s ensure yours does the job. These test cases for the login page cover bot-prevention flows:

• Confirm CAPTCHA appears after page load.
• Click refresh; a new challenge should display.
• Enter an invalid CAPTCHA; verify login is blocked with a clear error.
• Test timeout: leave CAPTCHA for >expiry time; ensure it expires.
• Verify audio/text alternatives for accessibility.
• Attempt multiple CAPTCHA failures; check for lockout or additional checks.
• Use OCR scripts/automation to test resistance.
• Inspect ARIA attributes for screen readers.

Cookie Test Cases

Cookies manage sessions — let’s keep them tight and secure. Incorporate these test scenario checks:

• Verify a session cookie is set on successful login.
• Ensure cookie persists across tabs but expires on logout or timeout.
• Check HttpOnly and Secure flags; the cookie isn’t JS-accessible.
• Manually alter cookies in DevTools; confirm session invalidation.
• Attempt simultaneous logins on two browsers; sessions must be isolated.
• Inspect domain/path scoping to prevent cross-site access.
• Confirm cookie lifetime matches policy (e.g., 30 minutes).
• Validate “Remember Me” cookie uses a separate, revocable token.

Gmail Login Page Test Cases

Gmail’s login is familiar, but it has its own quirks. Focus on what makes it unique, then refer to the general tests above. These Gmail login page test cases examples cover Google’s specifics:

• Home-Page Access: From gmail.com, click Sign In — does it load the login form?
• Recovery Flow: On forgotten password, does Gmail guide through email/phone recovery smoothly?
• Unrecognized Device Alert: Log in from a new location; verify security prompt or alert.
• Session Persistence: Test “Stay signed in” — does Gmail persist login across restarts?
• 2FA Challenge: Enable two-factor; confirm the OTP prompt and backup code flow.
• Accessibility: Ensure Google’s login fields and error messages read correctly in screen readers.
• Password Reveal Toggle: Test show/hide password icon for usability.
• Account Chooser: If multiple accounts exist, does Gmail let you switch easily?

Test Cases for the Login Page on the Mobile Application

Your mobile app’s login is like a key card reader on the go. Let’s make sure it works in every pocket. These test cases for mobile and test cases of login scenarios cover mobile nuances:

• Layout & Visibility on iOS and Android phones/tablets.
• Orientation Changes (portrait/landscape).
• Valid credentials login; session persists until explicitly logged out.
• Invalid credentials; clear, tappable error messages.
• Special characters in inputs — no crashes or glitches.
• “Forgot Password?” flow launches the system browser or in-app reset properly.
• “Remember Me” / “Stay Signed In” across app restarts.
• Multi-factor Authentication prompt integration (SMS, email, authenticator apps).
• Biometric login (fingerprint, face ID); deny access if unauthorized.
• Offline behavior: Does the app detect no network and show a helpful message?

BDD Test Cases for Login Page

Let’s understand BDD first: it’s called Behavior-Driven Development because it focuses on enhancing collaboration between developers, testers, and non-technical stakeholders by using natural language descriptions of the software’s behavior.

That’s why BDD uses plain language test scenario descriptions so everyone understands the behavior you expect. Here’s how to write test cases for login in Gherkin style:

Example 1. Valid Credentials

• Given valid credentials,
• When the user submits the login form,
• Then they should be redirected to their dashboard.

Multifactor Authentication (MFA)

• Given a user with MFA enabled,
• When correct credentials are entered,
• Then prompt for OTP and grant access upon verification.

Username with Special Characters

• Given a username containing !@#,
• When the user tries to log in,
• Then login succeeds or fails gracefully, per validation rules.

Additional Functionalities to Test

Real-world login pages often connect to more workflows. Let’s ensure these extras flow smoothly with clear scenarios for login page design and write test cases coverage.

Forgot Password Workflow

Steps:

• Click Forgot password? and enter a registered email or username.
• Verify receipt of reset email and correct reset link.
• Attempt reset with an expired link.
• Check that the new password meets complexity rules.
• Ensure old sessions are invalidated after reset.

Account Creation from Login Page

Steps:

• Click Sign Up; verify that the registration form loads.
• Test required fields and inline validation.
• Submit with duplicate email; expect a clear error.
• Complete the signup and verify email confirmation.
• Access the new account immediately after confirmation.

Multi-Language/Localization

Steps:

• Change browser or app language; verify translated text for labels, buttons, and errors.
• Confirm right-to-left layouts for RTL languages (Arabic, Hebrew).
• Input localized characters in credentials; the system handles them correctly.
• Test fallback when translation is missing (default to English).

Conclusion: Make Every Login Count

A reliable login experience doesn’t happen by accident — it takes thoughtful testing that goes far beyond checking valid usernames and passwords. From functional and security checks to performance, accessibility, and mobile compatibility, every test case helps create a smoother and safer user experience. The key is to prioritize critical scenarios, automate repetitive checks, and keep your test cases up to date as your application evolves.

Briefly, best practices for writing test cases for a login page include:

• Clear and Detailed Descriptions
• Include Positive and Negative Scenarios
• Focus on Security
• Reuse and Modularize Test Steps
• Ensure Coverage for Edge Cases
• Keep Test Data Organized
• Maintain Test Case Traceability

Remember, even the smallest login issue can frustrate users or put sensitive data at risk. With a solid testing strategy and the right test cases in place, you can turn your login page into a secure, seamless, and trustworthy gateway to your product.