Manual testing is the foundation of software quality assurance, especially in early-stage products or critical modules like login functionality. In this post, we’ll walk through a realistic manual testing scenario of a login page—covering test objectives, test cases, test data, expected results, and what to report.
Whether you’re a beginner or brushing up your skills, this example gives you a step-by-step process you can follow or adapt for interviews, projects, or training.
🧪 Test Objective
To validate that the login page functions correctly under various input conditions and follows expected behavior for authentication, validation, and error handling.
🔍 Test Scope
Includes:
- UI components
- Functional flows
- Input validation
- Error messages
- Security basics
Does not include:
- Backend security (e.g., SQL injection, HTTPS headers)
- API login validation (unless tested separately)
🖼️ Example Login Page Components
- Email/Username field
- Password field
- Login button
- “Forgot Password” link
- Validation messages
- Redirect after login
✅ Basic Test Scenarios
| Test Case ID | Test Case Description | Expected Result |
|---|---|---|
| TC-01 | Login with valid email and password | User is redirected to dashboard |
| TC-02 | Login with invalid email/password | Error message: “Invalid credentials” |
| TC-03 | Submit login form with empty fields | Validation message: “Email and password required” |
| TC-04 | Password field masks input | Input should appear as dots or asterisks |
| TC-05 | Click “Forgot Password” redirects to reset page | Redirects to password recovery page |
| TC-06 | Email input accepts invalid format (e.g., “user@com”) | Shows “Invalid email format” |
| TC-07 | Copy-paste works in both fields | User can paste credentials |
| TC-08 | Page loads correctly in Chrome, Firefox, Safari | Consistent rendering and functionality |
| TC-09 | Password field allows minimum and maximum character limits | Enforced per specs (e.g., 8–20 characters) |
| TC-10 | Session begins after login (check cookies or token if visible) | User stays logged in until logout |
🔐 Security Test Scenarios (Basic)
| Test Case ID | Description | Expected Result |
|---|---|---|
| TC-11 | Enter script tag in email field | Input is escaped or blocked |
| TC-12 | Try login attempts > 5 times | Account is locked or CAPTCHA is triggered |
| TC-13 | Use browser back button after logout | Session does not return to dashboard |
🧪 Sample Test Data
| Password | Notes | |
|---|---|---|
| [email protected] | Test@1234 | Valid login |
| [email protected] | wrongpass | Invalid password |
| invalid-email-format | Test@1234 | Invalid email format |
| [empty] | [empty] | Empty input test |
| [email protected] | Admin!2023 | Admin user test (if applicable) |
📋 Reporting a Bug Example
Title: Login page does not show validation for empty email
Steps to Reproduce:
- Open login page
- Leave email field empty
- Enter valid password
- Click “Login”
Expected Result:
Error message: “Email is required”
Actual Result:
Login button is disabled but no error is displayed
Severity: Minor
Environment: Chrome 123, Windows 11, QA environment
✅ Best Practices
- Test one scenario at a time
- Keep a checklist or spreadsheet to track Pass/Fail
- Use screenshots or recordings for failed cases
- Always confirm against the requirements or acceptance criteria
- Log bugs with clear reproduction steps
🧠 Final Thoughts
Manual testing of a login page might seem basic—but it’s one of the most important modules in any application. Done well, it prevents major access issues, user drop-offs, and security concerns.
Use this kind of structured approach not only for login pages, but also for other critical workflows like sign-up, checkout, and dashboards.
