Software Testing Jobs in E-commerce — Roles & Responsibilities

// Playwright — verify the core checkout flow in an e-commerce app
// This is the single most important test in any e-commerce QA suite.

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

test("customer can add to cart and complete checkout", async ({ page }) => {
  await page.goto("https://shop.example.com");

  // 1. Add an in-stock product to the cart
  await page.getByPlaceholder("Search products").fill("wireless earbuds");
  await page.getByRole("button", { name: /search/i }).click();
  await page.getByRole("link", { name: /wireless earbuds pro/i }).first().click();
  await page.getByRole("button", { name: /add to cart/i }).click();

  // 2. Go to cart and verify the item is there
  await page.getByRole("link", { name: /cart/i }).click();
  await expect(page.getByText("Wireless Earbuds Pro")).toBeVisible();
  await expect(page.getByText(/subtotal/i)).toBeVisible();

  // 3. Proceed to checkout
  await page.getByRole("button", { name: /checkout/i }).click();

  // 4. Fill shipping + payment (using sandbox credentials)
  await page.getByLabel("Full name").fill("Test User");
  await page.getByLabel("Address").fill("123 Test St");
  await page.getByLabel("Phone").fill("9876543210");
  await page.getByRole("radio", { name: /upi/i }).check();
  await page.getByRole("button", { name: /place order/i }).click();

  // 5. Verify order confirmation
  await expect(page.getByText(/order confirmed/i)).toBeVisible();
  await expect(page.getByText(/order id/i)).toBeVisible();
});

// What this proves in an interview:
// - You can test the highest-risk flow in e-commerce — checkout
// - You use accessible selectors, not brittle XPath
// - You verify success states, not just button clicks
// - You understand the flow real customers go through

// This single test is what an e-commerce QA interview
// will ask you to walk through — because a bug here
// costs the company real money.

// Postman — test a payment API's business logic
// E-commerce QA teams test payments more carefully than
// anything else — because the money is real.

// Request: POST {{baseUrl}}/api/payments/intent
// Body: { "orderId": "ORD-2026-0041", "amount": 49900, "currency": "INR" }

// Tests tab:

pm.test("status is 200 or 201", function () {
  pm.expect(pm.response.code).to.be.oneOf([200, 201]);
});

pm.test("response contains payment intent ID", function () {
  const body = pm.response.json();
  pm.expect(body).to.have.property("paymentIntentId");
  pm.expect(body.paymentIntentId).to.match(/^pi_/);
});

pm.test("amount matches the request", function () {
  const body = pm.response.json();
  pm.expect(body.amount).to.equal(49900);
  pm.expect(body.currency).to.equal("INR");
});

pm.test("status is pending or requires action", function () {
  const body = pm.response.json();
  const validStates = ["requires_action", "requires_confirmation", "pending"];
  pm.expect(validStates).to.include(body.status);
});

// What this proves in an interview:
// - You test business rules, not just HTTP status
// - You verify amounts and currencies — critical in payments
// - You check state machines, not just presence of fields
// - You know the difference between "requires_action" and "pending"

// In e-commerce QA, a payment bug is not a bug — it is
// a revenue incident. The tests above are the ones that
// guard against it.

-- SQL — verify an order in the database after a test
-- E-commerce QA testers use this constantly to confirm
-- that a successful UI flow actually persisted correctly.

SELECT
    o.order_id,
    o.status,
    o.total_amount,
    o.currency,
    p.payment_status,
    p.payment_gateway,
    p.paid_at,
    s.shipment_status
FROM orders o
LEFT JOIN payments p ON p.order_id = o.order_id
LEFT JOIN shipments s ON s.order_id = o.order_id
WHERE o.order_id = 'ORD-2026-0041';

-- Expected after successful checkout:
--   status            = 'CONFIRMED'
--   payment_status    = 'SUCCESS'
--   paid_at           IS NOT NULL
--   shipment_status   = 'PENDING_PICKUP' or 'PROCESSING'
--   total_amount      matches the cart total

-- After a failed payment:
--   status            = 'PENDING' or 'PAYMENT_FAILED'
--   payment_status    = 'FAILED'
--   paid_at           IS NULL
--   no shipment row created

-- After a refund:
--   status            = 'REFUNDED'
--   a refund record should exist with a timestamp
--   shipment_status   = 'CANCELLED' or 'RETURNED'

-- What this proves in an interview:
-- - You verify data persisted correctly across systems
-- - You understand the relationship between order, payment, shipment
-- - You check the failure paths too, not just success
-- - You can debug "the UI said success but no order was created"

-- This is what separates a junior tester from a QA engineer.
-- A junior checks the screen; an engineer checks the data.