Biggest Misconceptions About Working as a Software Tester

# Test Case Design — checkout flow
# These cases are written from the requirement, not from the code.
# Every testing interview tests whether you can design test cases this clearly.

## Feature: Checkout with a credit card

### Positive scenarios
1. Valid card + valid CVV + valid expiry → order placed, confirmation email sent
2. Saved card (no re-entry) → order placed
3. Valid card with 3D Secure → OTP flow shown, correct OTP → order placed
4. Same order placed twice (double-click) → only one order created (idempotency)
5. Order placed with coupon code → discount applied correctly

### Negative scenarios
6. Expired card → error "Card expired", no order created
7. Wrong CVV 3 times → card blocked for 24 hours, error message shown
8. Invalid card number → error "Invalid card", no charge
9. Insufficient funds → error "Insufficient funds", no order created
10. Payment declined by bank → error with retry option

### Boundary / edge cases
11. Minimum order amount boundary → charged correctly
12. Maximum order amount boundary → charged correctly
13. Amount just above max → error "Amount exceeds limit"
14. Order placed with 0 items in cart → blocked client-side and server-side
15. Very long coupon code (256 chars) → error, no crash

### Security scenarios
16. Card number never appears in logs or error messages
17. CVV never stored anywhere
18. Session token invalid after logout → cannot complete checkout
19. Rate limit on payment attempts → enforced after 5 attempts in 1 minute
20. Card number field only accepts digits, max 16 characters

# Why this matters:
# - This is what a real tester delivers, not "click checkout".
# - Every interview asks "how would you test X" — this is the answer.
# - Testers who can write this list do not fail technical interviews.
#
# What a great test case list shows:
# - You think about both positive and negative paths.
# - You know edge cases exist and where to find them.
# - You think about security even in functional testing.
# - You understand idempotency, sessions, and rate limits.

# Bug Report — the deliverable developers act on
# A great bug report saves hours of back-and-forth.
# A bad one — "checkout is broken" — gets ignored.

---

## Bug Report #4821

**Title:** Checkout fails silently when saved card CVV is wrong

**Severity:** High
**Priority:** P1
**Environment:** Web, Chrome 121, macOS 14, staging
**Reporter:** Ananya Sharma

## Steps to Reproduce
1. Log in as `test_user_01`
2. Add any item to cart, proceed to checkout
3. Select saved card ending in **4242**
4. Enter **wrong CVV** (e.g. `000`)
5. Click "Place Order"

## Expected
Error message "Incorrect CVV" shown; user stays on checkout page
and can retry.

## Actual
Button spins for 3 seconds and returns to same page with **no
error message**. Order is not created, but the user has no idea why.

## Evidence
- Screenshot: `checkout-cvv-fail.png`
- Console error: `net::ERR_ABORTED`
- Network: `POST /api/checkout → 400` with body `{"error":"invalid_cvv"}`
  (the frontend does not display this)

## Impact
Users with saved cards cannot tell why their order failed. Likely
high friction in payment completion — could cause cart abandonment.

## Suspected Cause
Frontend not handling `invalid_cvv` error from the API.

## Additional Notes
- Reproducible 100% of the time.
- Not related to browser or session state.
- Same issue may affect wrong-expiry and blocked-card errors.

---

# Why this matters:
# - This is what "good testing" produces: a fixable report.
# - The bug is described in steps a developer can execute in 30 seconds.
# - Expected and actual behaviour are clearly separated.
# - Evidence and suspected cause save debugging time.
#
# What a great bug report shows:
# - You tested thoroughly enough to know it is reproducible.
# - You understand the system (frontend, API, network).
# - You communicated clearly — not just "it's broken".
# - You gave the developer a head start on the fix.

// checkout.spec.ts — a real Playwright suite
// Automation is one part of a tester's job, not the whole job.

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

test.describe("Checkout flow", () => {
  test.beforeEach(async ({ page }) => {
    await page.goto("/login");
    await page.getByLabel("Email").fill("test_user_01@example.com");
    await page.getByLabel("Password").fill("CorrectPass123");
    await page.getByRole("button", { name: "Log in" }).click();
    await page.goto("/cart");
    await page.getByRole("button", { name: "Checkout" }).click();
  });

  test("valid card completes checkout", async ({ page }) => {
    await page.getByLabel("Card number").fill("4242424242424242");
    await page.getByLabel("Expiry").fill("12/28");
    await page.getByLabel("CVV").fill("123");
    await page.getByRole("button", { name: "Place Order" }).click();

    await expect(page).toHaveURL(/\/order-confirmation/);
    await expect(page.getByText("Order confirmed")).toBeVisible();
  });

  test("wrong CVV shows error and stays on checkout", async ({ page }) => {
    await page.getByLabel("Card number").fill("4242424242424242");
    await page.getByLabel("Expiry").fill("12/28");
    await page.getByLabel("CVV").fill("000");
    await page.getByRole("button", { name: "Place Order" }).click();

    await expect(page.getByText(/incorrect cvv/i)).toBeVisible();
    await expect(page).toHaveURL(/\/checkout/);
  });

  test("expired card is rejected", async ({ page }) => {
    await page.getByLabel("Card number").fill("4242424242424242");
    await page.getByLabel("Expiry").fill("01/20");   // past date
    await page.getByLabel("CVV").fill("123");
    await page.getByRole("button", { name: "Place Order" }).click();

    await expect(page.getByText(/card expired/i)).toBeVisible();
  });

  test("double-click place order creates only one order", async ({ page }) => {
    await page.getByLabel("Card number").fill("4242424242424242");
    await page.getByLabel("Expiry").fill("12/28");
    await page.getByLabel("CVV").fill("123");

    const button = page.getByRole("button", { name: "Place Order" });
    await Promise.all([
      button.click(),
      button.click(),        // simulate fast double-click
    ]);

    await expect(page).toHaveURL(/\/order-confirmation/);
    const orderId = await page.url().match(/order\/(\w+)/)?.[1];
    expect(orderId).toBeTruthy();

    // A separate API call would verify only one order exists — this test
    // checks that the frontend prevented the duplicate at the source.
  });
});

// What this shows an interviewer:
// - You test positive, negative, and boundary paths.
// - You use accessible locators (labels, roles) not brittle CSS.
// - You think about idempotency (double-click case).
// - You assert on user-visible outcomes, not just element presence.
// - You know that automation is one layer, not the whole job.
#
# What automation does NOT replace:
# - Exploratory testing (unscripted investigation)
# - Usability testing (does it feel right to a human)
# - Test design (what should we automate in the first place)
# - Judgement (which failures matter most)
#
# The strongest testers write automation AND think about what
# automation cannot cover.