The Bug Feedback Loop (Capstone)

Finding a bug is the start, not the finish. A bug you can't reproduce is a rumor. A bug report that makes an engineer come ask you questions has failed at its one job. And a bug that gets fixed but comes back six months later means the loop was never closed.

The full loop is: reproduce → report → fix → regression test. You own three of those four steps. In this capstone we'll walk the whole loop using a genuine, reproducible bug you can turn on in ShopKart: the lastname-swap scenario.

Step 1: Reproduce it reliably

Log into ShopKart, add any item, and open the checkout form with the bug on — [/shopkart/checkout?bugs=lastname-swap](https://resources.criodo.com/shopkart/checkout?bugs=lastname-swap). Type a first name, then a last name. Watch what happens.

Here's a test that captures the actual behavior. It passes against the live app — meaning it documents a bug that is really there:

import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';
import { InventoryPage } from '../pages/InventoryPage';
import { CheckoutPage } from '../pages/CheckoutPage';

test('BUG-001 repro: checkout last-name field overwrites the first name', async ({ page }) => {
  const login = new LoginPage(page);
  const inventory = new InventoryPage(page);
  const checkout = new CheckoutPage(page);

  await login.goto();
  await login.login();
  await inventory.addToCart('mi-usb-c-cable');

  // A bug scenario is turned on by the ?bugs= URL param, so we navigate
  // straight to the checkout form with it set (the cart already has an item).
  await page.goto('/shopkart/checkout?bugs=lastname-swap');

  await checkout.firstName.fill('Ada');
  await checkout.lastName.fill('Lovelace');

  // The bug: typing the last name overwrote the first name,
  // and the last-name field stayed empty.
  await expect(checkout.firstName).toHaveValue('Lovelace');
  await expect(checkout.lastName).toHaveValue('');
});

That's a real bug: with lastname-swap on, the checkout's last-name field writes into the first-name field, so the customer can never enter a valid last name and can't complete their order.

Before you report anything, nail down reproduction:

• Does it happen every time? Run it a few times. (This one does — 100% with the scenario on.)
• What's the minimal path? You don't need to browse ten products. Log in → one item → checkout → type two names. Strip the report down to that.
• What's the boundary? Remove the ?bugs=lastname-swap param and the same steps work fine. That contrast (bug on fails, bug off works) is gold for whoever fixes it: it isolates the trigger precisely.

> *A bug you can only reproduce "sometimes" isn't ready to report — it's ready to investigate. Intermittent repro usually means you haven't found the real trigger yet (a specific state, a timing window, a specific input). Find the trigger first. "Happens 100% with lastname-swap on, never with it off" is a finding; "happens sometimes" is a to-do.

A good bug report answers every question an engineer would ask, before they ask it. The non-negotiable fields:

BUG-001 — Checkout: last-name field overwrites first name

Severity: High        Priority: P1
Environment: resources.criodo.com/shopkart, Chrome 120, 2026-07-27
Scenario: bugs=lastname-swap (does not occur with the scenario off)

Steps to reproduce:
  1. Log in as student / crio123
  2. Add "Mi USB-C Cable" to the cart
  3. Open /shopkart/checkout?bugs=lastname-swap
  4. In "First Name" type: Ada
  5. In "Last Name"  type: Lovelace

Expected:
  First Name = "Ada", Last Name = "Lovelace"; order can proceed.

Actual:
  First Name = "Lovelace", Last Name = "" (empty).
  The last-name input writes into the first-name field. The customer
  cannot enter a valid last name and is blocked from completing checkout.

Evidence: trace.zip + screenshot attached (from the failing run).
Frequency: 100% reproducible with the scenario on; 0% with it off.

What makes this report actionable:

• Severity = how bad the impact is, technically. A property of the bug.
• Priority = how soon we should fix it. A business decision about scheduling.

Our bug blocks checkout — that's lost revenue — so it's High severity, P1 priority. Compare it to ShopKart's broken-images scenario: every product shows the same broken image. That's very visible, but the customer can still buy — so it's typically Medium severity and a lower priority than a checkout blocker. Ranking bugs by real user and business impact, not by how annoying they are to you, is a core QA judgment.

Write the test that asserts the correct behavior — the one that's red while the bug exists and green once it's fixed. This passes today with the scenario off (where the behavior is already correct) and stands guard forever:

// Regression guard for BUG-001. Fails if the last-name field ever
// starts overwriting the first name again. Note: no ?bugs= param.
test('BUG-001 regression: checkout fields persist independently', async ({ page }) => {
  const login = new LoginPage(page);
  const inventory = new InventoryPage(page);
  const checkout = new CheckoutPage(page);

  await login.goto();
  await login.login();
  await inventory.addToCart('mi-usb-c-cable');
  await inventory.goToCart();
  await page.locator('[data-test="checkout"]').click();

  await checkout.firstName.fill('Ada');
  await checkout.lastName.fill('Lovelace');

  await expect(checkout.firstName).toHaveValue('Ada');
  await expect(checkout.lastName).toHaveValue('Lovelace');
});

• The repro test documents the broken behavior as it exists now — it's your proof and your "is it fixed yet?" check.
• The regression test asserts the correct behavior — it goes green the moment the bug is fixed, then guards against its return forever.

• Reproduce: open the store with the bug on — [/shopkart/inventory?bugs=broken-images](https://resources.criodo.com/shopkart/inventory?bugs=broken-images) — and confirm every product shows the same broken image. Write a test that asserts the broken state. (Hint: collect the src of every [data-test="inventory-item-img"] and check they all point at the one 404.svg asset instead of distinct images.)
• Report: write the full report — severity, priority, minimal steps (including the ?bugs=broken-images scenario link), expected vs actual, evidence.
• Regress: turn the bug off and write the regression test that asserts the correct behavior (each product has a distinct, non-404 image) — it passes on the clean app and guards the fix.

Then repeat the loop for the other four scenarios in the control panel (cart-total, lastname-swap, slow-inventory, addtocart-fail). If you can do that cleanly, you can do the core job of a QA automation engineer: not just finding that something's broken, but turning it into something a team can fix and keep fixed.

You started this course able to drive a tool. You're leaving it able to do the job*: decide what's worth automating, turn requirements into cases, build a suite that survives change, kill flakiness, run it in CI as a real deploy gate, and close the bug loop. That judgment — not any single framework — is what makes a QA automation engineer. Finish with the quiz to lock it in.