Login Flow — Test Case Writing

Write a comprehensive manual test suite for a login page: functional cases, negative paths, security checks, and accessibility considerations, to interview-grade standards.

Role

Manual QA engineer

Difficulty

Beginner

Time limit

60–90 min

Scenario

You are a QA engineer joining a team mid-sprint. The development team has just completed the login feature for a new SaaS product. Your task is to write a test suite covering the login flow before it goes to staging. The application has: email + password login, a 'Forgot password' link, a 'Remember me' checkbox, and a 'Sign in with Google' SSO button. There is no test environment yet — you must write your test cases based on the requirements description alone.

Requirements

1.Write at least 20 test cases covering functional, negative, edge-case, security, and accessibility dimensions
2.Each test case must include: Test Case ID, Title, Preconditions, Steps, Expected Result, and Priority (Critical/High/Medium/Low)
3.Include at least 3 security-focused test cases (brute-force protection, SQL injection attempt, session behaviour after logout)
4.Include at least 2 accessibility test cases (keyboard navigation, screen reader label verification)
5.Group test cases by logical category (e.g. Happy Path, Negative, Security, Accessibility)
6.Identify which test cases are strong automation candidates and mark them

Starter data

›App name: Trackr (a project tracking SaaS)
›Login fields: Email (text input), Password (password input)
›Controls: Login button, 'Forgot password?' link, 'Remember me' checkbox, 'Sign in with Google' button
›Rules: Email must be a valid format; password must be at least 8 characters; account locks after 5 consecutive failed attempts for 15 minutes
›Session: JWT stored in an httpOnly cookie; 30-minute idle timeout; 'Remember me' extends session to 14 days
›Error messages: Use generic 'Invalid email or password' (no enumeration of which field is wrong)

Expected deliverables

✓A structured test case document (spreadsheet, Markdown table, or exported TestRail/Zephyr format)
✓Minimum 20 test cases with all required fields completed
✓A short paragraph (3–5 sentences) explaining your test case prioritisation rationale
✓A list of at least 5 questions you would ask the developer or product owner before testing begins

Evaluation rubric

Dimension	What reviewers look for
Coverage breadth	Does the suite cover happy path, negative paths, boundary values, security, and accessibility? Are edge cases like SQL injection, concurrent logins, and session expiry represented?
Test case quality	Are steps unambiguous and reproducible? Could a colleague with no prior knowledge of the feature follow them exactly and arrive at the same result? Are expected results observable and specific?
Prioritisation	Are Critical and High priorities assigned to the cases that would block a release if they failed? Is the rationale defensible? Would a low-priority case being marked Critical raise questions?
Security awareness	Are the security cases technically accurate? Does the SQL injection case use a real payload? Does the brute-force case test the threshold correctly (5th attempt, 6th attempt)?
Automation judgement	Are automation candidates the stable, high-value, repeatable cases — not the exploratory or one-off edge cases? Is the reasoning consistent?
Question quality	Are the developer/PO questions specific and actionable? Do they uncover ambiguity in the requirements (e.g. what happens if Google SSO fails? Is the lockout per IP, per account, or both?)?

Sample solution outline

›Group 1 — Happy Path (3 cases): valid credentials, valid credentials with Remember Me, SSO with a valid Google account
›Group 2 — Negative / Validation (7 cases): wrong password, unregistered email, empty email, empty password, both empty, invalid email format, password below minimum length
›Group 3 — Security (5 cases): 5th failed attempt triggers lockout, SQL injection in email field, password field does not echo in plain text, logout clears session cookie, concurrent login from two browsers
›Group 4 — Edge Cases (3 cases): login after 15-minute lockout expires, trailing/leading whitespace in email, extremely long email address (>254 chars)
›Group 5 — Accessibility (3 cases): all fields and buttons reachable via Tab key, Enter submits the form from the password field, email and password inputs have visible labels and aria-label attributes
›Automation candidates: Groups 1, 2 (all), Security cases 1+4+5 — stable, data-driven, and regression-safe

Common mistakes

Writing 'Enter valid credentials' as a step without specifying what 'valid' means — preconditions must state the exact test account to use
Marking every test case as Critical priority — if everything is critical, nothing is; reserve Critical for cases that block release or expose data loss
Forgetting to test the 'Remember me' session duration separately from a normal session — these are different flows with different expected behaviours
Writing only happy-path cases and adding one or two negative cases as an afterthought — a 20-case suite that is 18 happy-path cases is not a test suite, it is a script
Security test cases that are vague ('Try to hack the login') rather than specific ('Enter \' OR \'1\'=\'1 in the email field and observe the response')
Confusing 'Expected Result' with 'Test Objective' — expected result must be a specific, observable system response, not 'The test should pass'

Submission checklist

At least 20 test cases with all required fields (ID, Title, Preconditions, Steps, Expected Result, Priority)
Cases are grouped into logical categories
Minimum 3 security test cases with specific payloads or scenarios
Minimum 2 accessibility test cases
Automation candidates are marked consistently
Prioritisation rationale paragraph is included
At least 5 developer/PO questions are listed
No test case has 'Expected Result: Pass' — each has an observable, specific outcome

Extension ideas

+Write 5 test cases for the 'Forgot Password' flow, including the token expiry edge case
+Write a risk-based testing matrix mapping test cases to failure impact and likelihood
+Identify which test cases would need to be updated if the login flow added a CAPTCHA