Q14 of 38 · Manual & exploratory

Walk me through how you would write test cases for a login form.

Manual & exploratoryMidtest-case-designloginscenariosmid-level

Short answer

Short answer: Start with the spec, partition inputs (valid/invalid email, valid/invalid password), apply BVA on length boundaries, then layer in non-functional cases — security, accessibility, error messaging, rate limiting. About 25–40 cases is realistic.

Detail

A login form looks trivial but covers a surprising amount of test design ground. My approach is to think out loud across categories rather than enumerate randomly.

Functional positive: valid credentials → success; correct redirect; session established. Functional negative: wrong password, unknown user, empty fields, fields with leading/trailing whitespace. EP + BVA on email: minimum length, maximum length, exactly-at-boundary, malformed (no @, multiple @, unicode local part). EP + BVA on password: minimum length, maximum length, special characters, leading/trailing whitespace if allowed. Security: SQL injection, XSS in email field, brute-force attempts, no information leakage on error messages ("invalid email or password" not "user not found"), HTTPS-only POST. Rate limiting: N consecutive failures triggers lockout / captcha; lockout duration; reset behaviour. Session: login persists across reload; logout invalidates session; concurrent sessions across devices behave per spec. Accessibility: tab order, screen-reader error announcement (aria-live), labels associated with inputs, keyboard-only login. Internationalisation: error messages localised; non-ASCII emails work; RTL languages render correctly. Browser/device: works on supported browsers; mobile keyboards behave (no auto-capitalise on email). Edge: copy-paste, autofill, password manager fills, "remember me" persistence.

I'd also flag what I'd want answered before testing: lockout policy, password complexity, MFA, OAuth/SSO. The biggest junior mistake is testing only happy path + "wrong password" and stopping.

// EXAMPLE

login-test-cases.md

### High-priority cases

TC1   Valid login with correct credentials → redirect to dashboard
TC2   Wrong password shows generic error, no info leak
TC3   Unknown email shows the same generic error (no enumeration)
TC4   Empty email submits → inline validation, no API call
TC5   6 failed attempts within 5 min triggers lockout per spec
TC6   Email with leading/trailing whitespace is trimmed (or rejected)
TC7   Password field never visible in DOM as plain text
TC8   Tab order: email → password → submit → forgot password
TC9   Submitting via Enter key works
TC10  Login persists across page reload
TC11  SQL injection in email rejected, no 500 error
TC12  Screen reader announces error message (aria-live=polite)
TC13  Login page enforces HTTPS; HTTP request is redirected
TC14  Lockout duration matches spec; clears after policy-defined time
TC15  Concurrent login on two devices behaves per spec

// MODEL ANSWER

I approach this by thinking in categories rather than listing cases at random, and before writing anything I would ask: what is the lockout policy, is MFA in scope, and does SSO apply? Those answers define whole categories I need or can skip. Then I would work across seven areas: functional positive — valid credentials, correct redirect, session established; functional negative — wrong password, unknown email, empty fields, whitespace trimming; input boundaries — equivalence partitions on email format and password length, boundary value analysis at minimum and maximum; security — SQL injection, XSS in the email field, no information leakage in error messages so the message says invalid credentials rather than specifying which part was wrong, HTTPS-only POST; rate limiting — N failed attempts triggering lockout, duration, and reset behaviour; accessibility — tab order without a mouse, error messages announced via aria-live, inputs with associated labels; and session and edge cases — login persists on reload, logout invalidates the session, autofill and password manager work correctly. That gives roughly 25 to 40 test cases. The most common junior mistake is stopping at valid login and wrong password and considering it done.

// WHAT INTERVIEWERS LOOK FOR

Coverage breadth across functional, security, accessibility, and edge cases. Strong candidates flag what they'd ask the PM before testing (lockout policy, MFA, etc.).

// COMMON PITFALL

Listing only 'valid login / invalid password' — junior candidates routinely miss security, a11y, and i18n entirely.

// Related questions

Walk me through how you'd test a file upload feature end-to-end.

Manual & exploratory

How would you test a search feature for a marketplace site? List your test scenarios.

Manual & exploratory

How do you ensure your test cases stay maintainable as a product evolves?

Manual & exploratory