How would you test a login page?

I would start by asking questions, then design tests in layers: functional behaviour, input validation, security, session handling, and non-functional qualities such as accessibility and compatibility. Finally I would prioritise, because a login page has more possible tests than any sprint allows, and decide which belong in automation.

Clarify before testing

• Username, email, or phone? Case-sensitive?
• Password rules, lockout policy (how many attempts, how long), rate limiting?
• SSO, social login, MFA/2FA, “remember me”, password reset in scope?
• Session lifetime, concurrent sessions allowed?
• Supported browsers, devices, locales, accessibility standard (for example WCAG 2.2 AA)?

Interviewers often deliberately give no requirements to see whether you ask.

Functional

• Valid credentials log in and land on the correct page for that role.
• Wrong password, unknown user, both empty, one empty.
• Leading/trailing spaces in the username (trimmed or not, consistently).
• Email case: User@Example.com vs user@example.com.
• Password case sensitivity.
• Enter key submits the form; the button is not double-submittable.
• Deactivated, locked, or unverified accounts get the right message.

Validation and boundaries

• Minimum and maximum lengths for both fields (boundary values).
• Unicode, emoji, very long strings, pasted values with newlines.
• Client-side validation messages match server-side behaviour (bypass the UI with an API call to confirm the server validates too).

Security

• Error messages are generic (“Invalid email or password”) so they do not reveal which accounts exist (user enumeration).
• Lockout or throttling after N failures; it resets correctly.
• Password field is masked, not autocompleted where policy forbids it, never appears in URLs, logs or analytics.
• Login form and request are HTTPS only; session cookie has Secure, HttpOnly and a sensible SameSite.
• Basic injection probes (' OR '1'='1, <script>) are handled safely. Deep security testing is a specialist activity, but these smoke checks belong to QA.
• Session ID changes after login (session fixation).

Session behaviour

• Logout invalidates the session server-side; the back button does not show authenticated pages.
• “Remember me” persists only as long as specified.
• Idle and absolute timeouts.
• Login in two tabs or two devices behaves as designed.

Non-functional

• Keyboard-only navigation, visible focus, labels associated with inputs, errors announced to screen readers.
• Supported browsers and mobile viewports; password managers can fill the form.
• Response time under normal load; behaviour under slow network.

Prioritise and automate

I would run the core happy path and the main negative cases as a smoke test on every build, mostly through the API with one UI test, and keep exploratory sessions for odd inputs and multi-device behaviour.

What interviewers look for

• Asking about requirements before listing cases.
• Structure (categories) rather than a random list.
• Security and session thinking, not only “valid/invalid”.
• Prioritisation: what you would do first with limited time.