Why Ghaziabad Students Are Choosing Software Testing in 2026

# Feature: User login
# These test cases are written from the requirement — not the code.
# Every QA interview tests whether you can design test cases this clearly.

## Positive scenarios
1. Valid email + valid password → dashboard visible
2. Valid email + valid password (uppercase email) → dashboard visible
3. Valid email + valid password (trailing spaces in email) → dashboard visible
4. Remember-me checked → session persists after browser restart

## Negative scenarios
5. Valid email + wrong password → error "Invalid email or password"
6. Unregistered email + any password → same error message (no user enumeration)
7. Empty email → error "Email is required"
8. Empty password → error "Password is required"
9. Both empty → both field errors shown
10. SQL injection in email field → error, no crash
11. Very long email (300 chars) → error, no crash
12. Very long password (10,000 chars) → error, no crash

## Boundary / edge cases
13. Email without @ → error "Enter a valid email"
14. Email with spaces in the middle → error
15. Password exactly at minimum length → success
16. Password one character below minimum → error
17. Login attempt 5 times with wrong password → account lockout (if supported)

## Security scenarios
18. Session token missing after logout → cannot access protected routes
19. Password field masked in UI and not logged in plaintext
20. Rate limiting enforced after repeated failed attempts

# Why this matters:
# - Every product team needs someone who can write this list.
# - Beginners who skip test design and jump to Selenium cannot
#   write this — and cannot pass interviews.
# - This is the difference between a clicker and a QA engineer.
#
# How to practise:
# - Pick any login form you can access (a local app, a demo site).
# - Write 20 test cases just like this — positive, negative, edge,
#   security.
# - This one artefact, done well, is worth more than five
#   "automation course" certificates.

# test_api.py — API testing with pytest and requests
# API testing is where most modern QA work happens.

import requests
import pytest

BASE_URL = "https://api.example.com"

def test_get_user_returns_200():
    response = requests.get(f"{BASE_URL}/users/1", timeout=10)
    assert response.status_code == 200

def test_get_user_has_expected_fields():
    response = requests.get(f"{BASE_URL}/users/1", timeout=10)
    body = response.json()
    assert "id" in body
    assert "email" in body
    assert body["id"] == 1

def test_create_user_requires_email():
    payload = {"name": "Test User"}  # email deliberately missing
    response = requests.post(f"{BASE_URL}/users", json=payload, timeout=10)
    assert response.status_code == 400
    assert "email" in response.json()["message"].lower()

def test_login_with_invalid_credentials_returns_401():
    payload = {"email": "user@example.com", "password": "wrong"}
    response = requests.post(f"{BASE_URL}/login", json=payload, timeout=10)
    assert response.status_code == 401

@pytest.mark.parametrize("email", ["", "not-an-email", "a@b"])
def test_login_rejects_invalid_email_formats(email):
    payload = {"email": email, "password": "CorrectPass123"}
    response = requests.post(f"{BASE_URL}/login", json=payload, timeout=10)
    assert response.status_code == 400

# What this teaches:
# - Check status codes, response bodies, and error messages.
# - Test both the happy path and the failure paths.
# - Parametrize to cover many inputs with one test.
# - API tests are fast and stable — they belong in the middle
#   of the testing pyramid.
#
# Why Ghaziabad students should learn this early:
# - API testing roles are easier to enter than UI automation.
# - It requires less Selenium tooling and less browser knowledge.
# - It pays well and there is a clear ladder from API testing
#   into SDET.

// login.spec.ts — UI testing with Playwright
// End-to-end tests are slow and few. Use them for critical flows only.

import { test, expect } from "@playwright/test";

test.describe("Login flow", () => {
  test.beforeEach(async ({ page }) => {
    await page.goto("/login");
  });

  test("valid credentials log the user in", async ({ page }) => {
    await page.getByLabel("Email").fill("user@example.com");
    await page.getByLabel("Password").fill("CorrectPass123");
    await page.getByRole("button", { name: "Log in" }).click();

    await expect(page).toHaveURL(/\/dashboard/);
    await expect(page.getByText("Welcome back")).toBeVisible();
  });

  test("wrong password shows an error", async ({ page }) => {
    await page.getByLabel("Email").fill("user@example.com");
    await page.getByLabel("Password").fill("WrongPass");
    await page.getByRole("button", { name: "Log in" }).click();

    await expect(
      page.getByText("Invalid email or password")
    ).toBeVisible();
    await expect(page).toHaveURL(/\/login/);
  });

  test("empty password is blocked client-side", async ({ page }) => {
    await page.getByLabel("Email").fill("user@example.com");
    await page.getByRole("button", { name: "Log in" }).click();

    await expect(page.getByText("Password is required")).toBeVisible();
  });
});

// What this teaches:
# - Use accessible locators (labels, roles) instead of CSS selectors.
# - Assert on outcomes users care about: URL change and visible text.
# - Cover critical flows only — UI tests are the slowest layer.
# - Keep each test independent so failures are easy to diagnose.
#
# Playwright vs Selenium in 2026:
# - Playwright is faster, has better waiting, and is easier to install.
# - Selenium still has more jobs because enterprises have invested.
# - Learning one well means you can pick up the other in a week.
# - Do not switch tools every month — pick one and build depth.