Test cases for a login page
Updated 2026-11-12 · 6 min read
A login page looks simple and hides a lot of cases. Below are 40 grouped by type, with expected results, a CSV you can open in Excel or Google Sheets, and a way to answer the interview question in two minutes.
This assumes a page with an email or username field, a password field, a "Sign in" button, a "Forgot password" link and optionally "Remember me". Adjust for your product: if it has OTP or social login, add those cases.
How to answer this in an interview
Do not start listing. Say: "I would group the tests: functional, negative, boundary, UI, security, performance and compatibility. Let me give the important ones from each." Then give three or four from each group, and finish with "and I would ask what the lockout rule and password policy are, because they change the expected results." That last sentence shows you test requirements as well as screens.
Functional
| ID | Category | Test case | Expected result |
|---|---|---|---|
| L01 | Functional | Log in with a valid username and valid password | User reaches the dashboard and sees their own name |
| L02 | Functional | Press Enter in the password field instead of clicking the button | Form submits and login succeeds |
| L03 | Functional | Log in with a valid email typed in a different case ([email protected]) | Behaves as documented; email matching is normally case-insensitive |
| L04 | Functional | Log in with leading or trailing spaces around the email | Spaces are trimmed and login succeeds, or a clear message is shown |
| L05 | Functional | Tick "Remember me", close the browser, reopen the site | User remains signed in for the documented period |
| L06 | Functional | Leave "Remember me" unticked, close the browser, reopen | User is signed out |
| L07 | Functional | Click "Forgot password" | Reset page opens |
| L08 | Functional | Log in, then log out, then press the browser Back button | Protected pages are not shown; user is sent to login |
| L09 | Functional | Open the login page while already signed in | User is redirected to the dashboard (or sees a sign-out option) |
| L10 | Functional | Log in after a password change with the old password | Login fails with the standard error message |
Negative
| ID | Category | Test case | Expected result |
|---|---|---|---|
| L11 | Negative | Valid username, wrong password | Generic error such as "Email or password is incorrect" |
| L12 | Negative | Unregistered username, any password | The same generic error; it must not reveal that the account does not exist |
| L13 | Negative | Both fields empty | Inline messages for both required fields; no request is sent |
| L14 | Negative | Username filled, password empty | Message on the password field |
| L15 | Negative | Invalid email format (asha@, asha.example.com) | Format error shown before submitting |
| L16 | Negative | Wrong password repeated past the lockout limit (for example 5 times) | Account is locked or throttled with a message, per the requirement |
| L17 | Negative | Try the correct password after the lockout starts | Still blocked until the lockout ends or is reset |
| L18 | Negative | Log in with a deactivated or unverified account | Clear message about the account state |
| L19 | Negative | Submit the form twice quickly (double click) | One request is processed; no duplicate session or error |
| L20 | Negative | Submit while the network is offline | Friendly error; fields keep their values (except the password if designed so) |
Boundary
| ID | Category | Test case | Expected result |
|---|---|---|---|
| L21 | Boundary | Password of exactly the minimum allowed length | Accepted if correct |
| L22 | Boundary | Password one character shorter than the minimum | Rejected |
| L23 | Boundary | Password of the maximum allowed length, and one longer | Maximum works; longer is rejected or truncated as documented |
| L24 | Boundary | Email of 254 characters, and 255 | 254 handled; 255 rejected cleanly (no server error) |
| L25 | Boundary | Password containing spaces, unicode and emoji | Treated as normal characters; login works with the same password |
UI and usability
| ID | Category | Test case | Expected result |
|---|---|---|---|
| L26 | UI | Password field masks input; the show/hide icon toggles it | Works, and the icon has an accessible label |
| L27 | UI | Tab order moves email, password, remember me, sign in, forgot password | Logical order; focus is visible |
| L28 | UI | Error messages are readable and appear next to the field | Yes; colour is not the only signal |
| L29 | UI | Open on a 360px wide phone, and rotate | No horizontal scroll; the keyboard does not hide the button |
| L30 | UI | Browser password manager offers to save and autofill | Fields use correct autocomplete attributes |
Security
| ID | Category | Test case | Expected result |
|---|---|---|---|
| L31 | Security | Enter ' OR '1'='1 in the username | No login; handled as normal text with the standard error |
| L32 | Security | Enter <script>alert(1)</script> in the fields and see if it is echoed back | Never executed; any echo is encoded |
| L33 | Security | Check the page is served over HTTPS and the form posts over HTTPS | Yes, with no mixed content |
| L34 | Security | Inspect the request: is the password in the URL or in plain text logs? | Sent in the request body only, over HTTPS |
| L35 | Security | After login, check the session cookie flags | HttpOnly and Secure set; a new session id is issued on login |
| L36 | Security | Log in on two browsers, then change the password | Other sessions end if the requirement says so |
| L37 | Security | Replay the login request many times from a script | Rate limiting or captcha appears |
Performance and compatibility
| ID | Category | Test case | Expected result |
|---|---|---|---|
| L38 | Performance | Time a login under normal load | Within the agreed limit (for example under 2 seconds) |
| L39 | Compatibility | Repeat L01 on the latest Chrome, Firefox, Safari and Edge | Same result on all |
| L40 | Compatibility | Repeat L01 on Android Chrome and iOS Safari | Same result on both |
Automating these
Start with L01, L11, L13 and L16 as the smoke set. You can try them on the practice playground login page, which has stable element IDs for exactly this.
Downloads
Quick answers
How many test cases should I write for a login page in an interview?
You are not expected to list forty. Name the categories (functional, negative, boundary, UI, security, performance, compatibility) and give two or three strong examples from each. Structure matters more than count.
What are the most important test cases for login?
Valid login, invalid password, invalid username, empty fields, account lockout after repeated failures, password masking, session handling after logout, and protection against SQL injection in the inputs.
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.
