How to Write Test Cases for a Login Page (2026 Template + 40 Examples)

The login page is the single most-asked artefact in QA interviews and the first feature you'll touch on almost every project. If you can write clean, thorough test cases for a login page, you can write them for anything.

This guide gives you a battle-tested template, 40 example test cases covering functional, UI, security and performance scenarios, and the exact mindset hiring managers look for. Pair it with our manual testing interview questions and rehearse aloud in the AI Mock Interview.

A login test case is a documented set of steps that verifies one specific behaviour of the authentication flow — for example, "valid user with correct password is redirected to the dashboard". Good login test cases are atomic, repeatable, independent and tied to a clear expected result.

Use this template for every test case you write:

For complex flows, layer test design techniques like Equivalence Partitioning, Boundary Value Analysis and Decision Tables — covered in depth in our manual testing interview guide.

1. Login with valid email and valid password → redirected to dashboard.
2. Login with valid email and invalid password → "Invalid credentials" error, no redirect.
3. Login with unregistered email → generic "Invalid credentials" error (no user enumeration).
4. Login with empty email field → inline "Email is required" validation.
5. Login with empty password field → inline "Password is required" validation.
6. Login with both fields empty → both inline validations shown, Sign in disabled.
7. Login with leading/trailing spaces in email → trimmed and accepted.
8. Login with email in mixed case (USER@Test.com) → accepted (emails are case-insensitive).
9. Login with password in wrong case → rejected (passwords are case-sensitive).
10. "Remember me" checked → session persists after browser restart.
11. "Remember me" unchecked → session cleared on browser close.
12. "Forgot password" link → opens /reset-password route.

13. Email field placeholder reads "you@company.com".
14. Password field masks characters by default.
15. Show/Hide password toggle reveals plain text on click.
16. Sign in button is disabled until both fields contain text.
17. Tab order is Email → Password → Remember me → Sign in.
18. Pressing Enter in any field submits the form.
19. Error messages are announced to screen readers (aria-live="polite").
20. Layout renders correctly at 320px, 768px, 1024px and 1440px viewports.

21. Password is sent over HTTPS only (verify in DevTools → Network).
22. Password is never echoed in URL, logs or cookies.
23. Account locks for 15 minutes after 5 consecutive failed attempts.
24. Brute-force attempts trigger CAPTCHA after 3 failures.
25. SQL injection in email field (' OR 1=1 --) is rejected and logged.
26. XSS payload in email field (<script>alert(1)</script>) is escaped on render.
27. Session cookie is HttpOnly, Secure and SameSite=Lax.
28. JWT (if used) expires within the documented TTL.
29. Logout invalidates the session server-side (replaying the old cookie fails).
30. Password reset link expires after a single use or 30 minutes.

Negative test design overlaps heavily with the API security work covered in our API testing interview questions.

31. Login response time < 2 seconds on a 4G connection.
32. Login page LCP < 2.5 seconds on mobile.
33. Login succeeds under 500 concurrent users (load test).
34. Login page works on Chrome, Firefox, Safari and Edge (latest 2 versions).
35. Login page works on iOS Safari and Android Chrome.
36. Login page is keyboard- and screen-reader-accessible (WCAG 2.2 AA).

37. Login with a deleted user account → "Account no longer exists".
38. Login with a disabled / suspended account → "Account suspended, contact support".
39. Login with an unverified email → prompt to resend verification email.
40. Login during a server outage → friendly 503 page, no stack trace.

• Writing one giant test case that covers 10 scenarios — keep them atomic.
• Hard-coding test data inside steps — externalise to a data sheet or fixtures file.
• Skipping negative cases — that's where real bugs live.
• Forgetting accessibility and mobile viewports.
• Treating security as "someone else's job" — every QA owns it.

Convert these 40 cases into automated tests with our Playwright framework setup guide, then practice walking a hiring manager through your approach in the AI Mock Interview. If you're prepping for an interview round, also review the manual testing interview Q&A and the ATS-friendly QA resume checklist.

Bookmark the official OWASP Top 10 for the security cases above — interviewers love candidates who can name the threat model behind each test.

Reference numbers for how many test cases a real 2026 login page ships with, and where the escaped-defect risk actually lives. Aggregated from OWASP Authentication Cheat Sheet metrics, Auth0 / Okta 2026 State of Authentication reports, and a SoftwareTestPilot audit of 74 production login flows (Q1 2026).

Read: everyone covers happy-path and field validation — that's not where bugs escape. The escaped-defect column shows that rate-limiting, MFA, SSO, and auth-security together drive ~68% of production login incidents, but fewer than half of teams write tests for them. Prioritise those four buckets first.