From a production bug to a regression test in 30 minutes

Tuesday, 9:47 AM. Slack ping: "Customer paid but order still shows Pending."

This case is fictional but painfully familiar — the kind of bug small teams see after an auth refactor or webhook change. The goal isn't drama. It's the workflow: incident to test asset in about 30 minutes.

Minutes 0–5: Confirm and narrow

Symptom: Stripe payment succeeds, UI stuck on "Processing", no confirmation email.

First move isn't a fix — it's reproduction:

1. Test account + card 4242… on staging.
2. Checkout on desktop Chrome → pass.
3. Repeat on mobile Safari, refresh right after redirect → fail: order stays Pending.

Quick hypothesis: payment_intent.succeeded webhook arrives before the session cookie is set post-redirect — race condition.

Log environment, role, timestamp, request id if available. Don't touch code until you've reproduced at least once.

Minutes 5–15: Dev fixes, QA holds context

Dev adds idempotency + a retry job to sync order status when the webhook wins the race.

Meanwhile QA:

• keeps repro steps tight (five steps, no fluff)
• captures HAR/network on failure
• states expected: order reaches Paid within 30 seconds after redirect

Fix lands on staging. QA verifies manually three times: desktop, mobile Safari, early refresh.

Minutes 15–25: Write the regression test (Playwright)

Rule of thumb: memorable production bug → one regression test.

// pseudo — test idea
test('order reaches Paid after checkout even if user refreshes early', async ({ page }) => {
  await loginAsTestBuyer(page);
  await page.goto('/checkout');
  await completeStripeTestPayment(page);
  await page.reload(); // simulate eager refresh
  await expect(page.getByRole('status')).toHaveText(/paid/i, { timeout: 30_000 });
});

The test should:

• use stable seeded user + product
• not depend on other tests' order
• fail with a clear message

For Playwright setup patterns we use in real teams, see Playwright in real software teams.

Minutes 25–30: Ship again and close

Pre-prod deploy:

• New regression test green on CI
• Login + checkout smoke green on staging
• Two-line postmortem: root cause + prevention

After deploy: run prod smoke with safe test data. Close the ticket; link the test PR.

Checklist: incident → test asset

## Incident → test asset

### 1. Capture (≤ 5 min)
- [ ] User-facing symptom (one sentence)
- [ ] Environment + version/build
- [ ] Minimal repro steps
- [ ] Severity / affected users

### 2. Resolve (≤ 15 min)
- [ ] Dev fix + QA verify on staging
- [ ] Expected result written clearly

### 3. Test asset (≤ 10 min)
- [ ] Regression test encodes the old bug
- [ ] Test data / seed documented
- [ ] Test runs on CI (PR or nightly)

### 4. Ship & learn
- [ ] Post-deploy smoke
- [ ] Link test ↔ ticket
- [ ] One line: "next time we prevent this by..."

Small lesson

Thirty minutes isn't magic — it's a deadline that stops the team at hotfix-only. Hotfix without a test is just scheduling the same incident next week.

Automation doesn't replace QA judgment. It locks that judgment into something that runs every night.

---

Next incident: time yourself from Slack ping to green test.