Lesson 1 of 86 min read
Scenario: testing a login page
The most common interview scenario and the first feature many testers get. Think beyond 'valid and invalid password'.
Key takeaways
- 1Functional: valid login, wrong password, unknown email, empty fields, email case, Remember me, logout.
- 2Security: password masked, lockout after repeated failures, no hint whether the email exists, session ends on logout.
- 3Usability: Enter key submits, tab order, clear error messages, show/hide password, works on mobile.
Sample test cases
TC01 Valid email + password -> dashboard opens TC02 Valid email + wrong password -> 'Invalid email or password' (generic) TC03 5 wrong attempts -> account locked / captcha TC04 ' ASHA@test.dev ' with spaces and capitals -> handled consistently TC05 Log out, press browser Back -> must not show the dashboard TC06 Copy dashboard URL into a private window -> redirected to login
Go deeper
Expert notes beyond the basics
- 01
Account lockout needs its own test plan
Lockout protects against brute force, but a badly built lockout becomes its own bug. Test: does the counter reset after a successful login, or does it keep counting forever? Does it reset after a fixed time, like 30 minutes, or only after an admin unlocks it? Can an attacker lock out a victim just by typing their email with wrong passwords repeatedly (this is called a denial-of-service through lockout)? Also check that the lockout message does not reveal whether the account exists, and that locked users still get a clear way to recover access, such as a reset email.
- 02
Multi-factor and social login add new paths
If the app supports OTP or an authenticator app, test wrong OTP, expired OTP, resend limits, and OTP reuse after it was already consumed. For 'Login with Google' or 'Login with Facebook', test what happens when the social account's email already exists as a normal account (should they merge or conflict?), when the user denies permission on the provider's screen, and when the token from the provider expires mid-flow. These are easy to forget because they live outside your own app's code.
- 03
Accessibility and keyboard-only login
A screen reader user should hear meaningful labels, not just 'textbox'. Tab order should move logically from email to password to the login button, and the Enter key should submit the form from either field. Error messages must be announced, not just shown as a colour change, since colour-blind or screen-reader users won't notice a red border alone. Test with keyboard only: no mouse, can you log in end to end using Tab, Shift+Tab and Enter?
- 04
Session and token details interviewers love
Check what happens when a session expires while the user is mid-task: does it silently fail, or redirect to login with a message explaining why and, ideally, return the user to the same page after re-login? Check concurrent sessions: can the same account be logged in on two browsers at once, and should it be allowed? Check 'Remember me': does it extend the session length or just pre-fill the email, and does it still require a password?
Common mistakes to avoid
- - Testing login only on the main browser and skipping Safari, where autofill and password managers behave differently.
- - Never testing what happens when the session cookie or token is deleted manually mid-session.
- - Forgetting to test login while the account is mid-password-reset, such as using the old password after requesting a new one.
- - Assuming 'password field is masked' is enough security testing, without checking lockout, generic errors or session handling after logout.
Login page test cases
A starting set to extend for your own project.
| ID | Scenario | Steps | Test data | Expected result | Priority |
|---|---|---|---|---|---|
| TC01 | Valid login | Enter email and password, click Login | registered@test.dev / Valid@123 | User is redirected to dashboard | High |
| TC02 | Wrong password | Enter valid email, wrong password | registered@test.dev / WrongPass1 | Generic error: 'Invalid email or password' | High |
| TC03 | Unregistered email | Enter an email that does not exist | nouser@test.dev / Any@123 | Same generic error as TC02 | High |
| TC04 | Account lockout | Enter wrong password 5 times in a row | registered@test.dev / wrong x5 | Account locked, captcha or cooldown shown | High |
| TC05 | Empty fields | Click Login with both fields empty | blank / blank | Inline validation on both fields, no server call | Medium |
| TC06 | Case-insensitive email | Login with uppercase email | REGISTERED@TEST.DEV / Valid@123 | Login succeeds same as lowercase | Medium |
| TC07 | Session after logout | Logout, then press browser Back | logged-in session | Dashboard is not shown; redirected to login | High |
| TC08 | Keyboard-only login | Use Tab and Enter only, no mouse | registered@test.dev / Valid@123 | Login completes successfully | Low |
Try it yourself
Write 6 test cases for a 'Forgot password' link on the login page, beyond the basic 'enter email, get a link' flow.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
How would you test a login page?
Model answer
I group tests: functional (valid/invalid combinations, empty fields, remember me), security (masking, lockout, generic errors, session after logout, back button), UI/usability (tab order, Enter key, messages, mobile) and non-functional (response time, works across browsers). I prioritise valid login and security first.
- Q2
How would you test 'Remember me' on a login page?
Model answer
Check it keeps the user logged in after closing and reopening the browser, that it doesn't work after an explicit logout, that unchecking it logs the user out when the browser closes, and that it still requires correct credentials to enable in the first place. I'd also check it on a shared or public computer scenario for security risk.
- Q3
A tester logs in, the page hangs for 10 seconds, then logs in successfully. Is this a bug?
Model answer
It depends on agreed performance expectations, but a 10-second login is usually unacceptable to users and worth logging as a performance defect with evidence from the Network tab, such as which request took long. I'd check if it's consistent or a one-off, and under what load.
- Q4
How would you test login on a page available in multiple languages?
Model answer
Check that error and success messages are translated correctly and don't overflow the layout, that email and password fields accept the same valid input regardless of language, that date or number formats elsewhere don't affect login, and that switching language mid-login doesn't lose entered data.
Knowledge check
+5 points
After logout, the user presses Back and sees the dashboard. This is: