Test Cases for Login Page: The Complete Checklist

Below you get 80 test cases for login page validation in one table, with IDs, expected results, and priorities you can paste straight into your test management tool. After the checklist, you will delve into the categories where the expected result needs explaining, from session security through WebAuthn, PKCE, and account recovery.

A solid login test case names one scenario, states its preconditions and data, and defines an outcome your team can verify on the client and the server.

One scenario per case keeps your failures diagnosable, because when a run goes red, the ID alone tells your team which behavior broke. Anyone working out how to write test cases for login page scenarios should start from this structure, and our guide on how to create test cases covers the format in full.

Here is the full checklist, grouped by category and ordered by the sequence your team would run it. These sample test cases for login page coverage mix positive and negative scenarios, with priorities that assume a customer-facing product with password login, MFA, and at least one federated option.

Copy the table into your tool, delete the rows for capabilities you do not ship, and then work through the sections below for the categories where the expected result needs context.

Two functional areas produce most of the incidents that reach your production environment.

• Return URL handling splits into two cases. LOGIN-002 confirms your user lands on the internal page originally requested, while LOGIN-003 confirms a tampered or external URL gets refused. Since these are different failures with different fixes, they stay separate.
• Concurrency. A double-clicked submit button in LOGIN-004 and a back button after logout in LOGIN-005 both produce states that a single scripted run never reaches, yet your users hit them daily.

Form behavior earns its own category, because these defects reach every one of your users while breaking nothing on the server.

• Password manager autofill, LOGIN-010. Scripts that block autofill push people toward passwords they can retype from memory, which are weaker by definition.
• Focus placement after an error, LOGIN-012. Keyboard and screen reader users need focus on the failing field so they can correct a typo without hunting for it.
• Button state, LOGIN-011. When your form has no disabled state during submission, you get the duplicate requests covered by LOGIN-004.

These possible test cases for login page hardening prove that malformed input fails safely at your server, and not only in the browser.

• Removing maxlength in dev tools takes ten seconds, so any limit your UI enforces alone is decorative.
• Injection cases belong in a dedicated security suite, separate from your login smoke tests, since mixing the two makes both harder to maintain.
• Validation text leaks state. A message flagging an invalid username format during a wrong-password attempt confirms to an attacker that the account exists.

AI-generated image.

Enumeration leaks through four channels, so your team compares all of them side by side.

• Error text. OWASP recommends one generic message covering unknown users, wrong passwords, and disabled accounts.
• HTTP status codes. A 404 for missing users against a 401 for wrong passwords is enumeration one layer down.
• Response timing. An instant rejection for an unknown user against 200 ms for a real password check becomes measurable across thousands of attempts.
• Redirect behavior. Different destinations or response sizes give the same information away.

Record the visible message alongside the raw network response for each account state, then repeat every run to average out network noise. Because identical timing is impossible in practice, LOGIN-029 targets the absence of a consistent, exploitable difference.

These three patterns trigger different defenses, so they need separate cases against controlled accounts in a dedicated environment.

OWASP warns that purely IP-based controls fall to distributed attacks, which is exactly what LOGIN-033 measures for you. LOGIN-031 then covers the opposite risk: if five bad passwords lock any account for an hour, a script and a list of email addresses can lock out your entire user base.

Session fixation succeeds when the identifier survives authentication, so LOGIN-035 records your anonymous session ID and compares it after login. Among all test cases for login page in software testing, this cluster catches the defects that static review misses most often.

Transport cases stay simple by comparison: open your login page over HTTP, submit the form over HTTP, rewrite the form action, and confirm credentials never appear in query parameters, since URLs land in browser history, server logs, and analytics pipelines.

A working login screen says nothing about the resources behind it, because web interfaces routinely redirect anonymous users while the underlying API answers unauthenticated requests. Request /account, /admin, and every API route your frontend calls with no session at all, then repeat the run with edited client-side state such as isLoggedIn in local storage or a modified role parameter.

Replay protection has a published requirement behind it: OWASP ASVS 5.0 states that lookup secrets, out-of-band codes, and TOTPs are successfully usable only once.

• LOGIN-046. Authenticate with a code, then immediately retry the same value before expiry. Success on that second attempt is a defect with a standard reference attached.
• LOGIN-050. Our experts advise testing MFA removal with the same identity checks your enrollment required, since an emailed link with no verification hands your second factor to anyone holding the mailbox.
• Method downgrade. Switching from a hardware key to SMS should require authorization, because attackers always target the weakest factor you allow.

Your security-relevant passkey cases sit in the ceremony itself, where the server verifies the challenge, the origin, and the signature.

• Never mock the callback. Frontend automation that fakes a successful WebAuthn response proves nothing, since LOGIN-051 through LOGIN-055 all assert server-side validation.
• Conditional UI. When your form offers passkeys inline with the password field, confirm it detects available credentials, degrades cleanly when the device is unreachable, and never blocks password entry.
• Sessions stay identical. Every case from LOGIN-035 to LOGIN-040 applies to your passkey logins unchanged.

Magic links move the security boundary to the email channel and the token, so treat each link as a single-use credential with an expiry.

Token issuance also needs a documented policy your case can assert. When your user requests a second link while the first one remains valid, either the old token dies immediately or both stay usable until expiry, and LOGIN-057 through LOGIN-060 verify whichever behavior your product promises.

A “Continue with Google” button moves credential handling to an identity provider while leaving session security with your app, so the protocol failures never appear in browser-only tests.

• State, nonce, and PKCE. LOGIN-062 covers CSRF protection on the callback, LOGIN-064 rejects an invalid or reused OIDC nonce, and LOGIN-065 fails the token exchange when the PKCE code_verifier does not match the original challenge.
• Code replay. LOGIN-063 submits the same authorization code twice, which your token endpoint must refuse.
• Strict redirect URI matching. Loose matching leaves you with an open redirect waiting for traffic.
• SAML attribute mapping. Provisioned accounts need correct group and role claims, plus defined behavior when the provider session expires ahead of yours.
• Federated logout. Mismatched expectations here generate support tickets your team answers for months afterward.

These cases support WCAG 2.2 AA conformance and may also be required by accessibility rules applying to your product, including Accessible Authentication (Minimum).

• W3C documents blocked paste as failure F109, so a password field that forces manual entry fails unless you provide an accessible alternative. Split OTP boxes create the same barrier when a pasted code populates only the first box.
• Automated scanners detect missing labels and broken ARIA attributes, although they cannot confirm what a screen reader actually announces. Manual runs with NVDA, JAWS, or VoiceOver therefore stay in your scope.
• Plain language applies to your error text as well. “Wrong username or password” serves everyone, while “Authentication failed due to invalid credentials provided during the login attempt” serves nobody.

Run these in a controlled environment with dedicated accounts, because a load test against production triggers your own rate limiting and distorts every number you collect.

• Authentication latency at the median and 95th percentile, plus your error rate during a traffic spike.
• Identity provider response time, MFA delivery latency, and session store throughput under concurrent logins.
• Failure behavior: a slow account database times out with a clear message, an MFA provider outage leaves your backup codes usable, and a dropped connection never surfaces to your user as “wrong password”.

Assign each case to the cheapest layer that can prove it, since running 80 scenarios through a browser is slow and brittle.

One change saves your team more time than any other: stop logging in through the UI before every test. Instead, create authenticated state through API calls or reusable fixtures, keep a small suite exercising your login interface itself, and let everything else start from an authenticated session. Documenting 80 cases by hand costs days, which is why an ai test case generator working from your own requirements has become part of the workflow.

AI-generated image.

Five clusters carry the highest damage when they fail on you.

• LOGIN-027 to LOGIN-029. A single difference in text, status, or timing hands attackers your user list.
• LOGIN-043. A working login screen and an open API endpoint coexist far more often than your team expects.
• LOGIN-035 and LOGIN-037. Without ID rotation and server-side logout, planted or stolen sessions stay valid.
• LOGIN-030 and LOGIN-031. Proof that brute force gets stopped while your legitimate users stay unlocked.
• LOGIN-010 and LOGIN-074. Authentication does not block password managers or copy and paste without providing an accessible alternative.

Each example of test cases for login page documentation below shows the detail a single checklist row expands into for your suite.

LOGIN-013: Invalid password

• Scenario: Registered user submits a wrong password
• Preconditions: Active account, correct username, password WrongPass999!
• Steps: Open login page enter username enter wrong password submit
• Expected result: Generic “Invalid credentials” error, no session cookie, failure counter increments, response text and HTTP status identical to an unknown-user attempt
• Priority: Critical

LOGIN-030: Throttling threshold

• Scenario: Rate limiting engages at the configured number of failures
• Preconditions: Active account, policy set to 5 attempts
• Steps: Submit an incorrect password 5 times submit the correct password wait out the cooldown submit the correct password again
• Expected result: Throttling engages on attempt 5, correct password handled per policy during cooldown, access restored afterward, counter reset on success
• Priority: Critical

Keep your expected results this specific, because a case reading “verify locked account behavior” with no threshold data stalls whoever inherits it. You will find more formats in our test case template collection.

Coverage scales with the authentication methods a product ships, so the total depends on its architecture and regulatory exposure. A password-only form with no federation requires roughly 40 cases. Adding MFA, SSO, passkeys, and magic links brings the suite to all 80 in the checklist above.

These figures are planning estimates and not a quota. Fifty shallow cases confirming that a Login button renders will miss a session fixation defect, while the six session cases in this checklist detect it on the first run.

Three factors adjust the total. Products in payments or healthcare add documented evidence for SOC 2 or PCI DSS, which raises both the case count and the traceability auditors expect. Linking that evidence to requirements inside aqua cloud prevents rebuilding the paper trail every cycle. Test cases for registration page flows belong to a separate suite and stay outside this count. Unsupported capabilities, such as SAML provisioning or hardware keys, come out of the table entirely, because coverage of unreachable scenarios demonstrates nothing.

Authentication is the one component every user hits and the first target of automated traffic. The 15 Critical rows in the checklist cover enumeration, session rotation, throttling, and bypass, which makes them the first sprint. Six to eight UI cases are enough for the form itself, while account states and cookie assertions run faster at API and protocol level. Each architectural change extends the list: passkeys add LOGIN-051 to LOGIN-056, OIDC adds the nonce and PKCE cases, and every audit cycle converts those expected results into evidence.