Work sample · Manual & exploratory QA

Manual testing
still matters

Type Exploratory testing · Bug report Includes A live, reproducible demo

1. The claim

Automated regression suites are valuable. They run fast, run often, and never get bored. But a green test run is not the same as a working product. An automated suite only checks what it was written to check. A human tester checks what a real user actually does.

This has come up across my testing work in banking, telecom and streaming: more than once, the automated checks passed while exploratory testing still found a real bug.

Here is a small demo where you can see it happen.

Try to find the bug yourself

A tiny subscription-purchase demo. No account needed. Try clicking around like a real, slightly impatient user would, before reading the explanation below.

Open the demo →

2. The automated test, and why it passes

Here is the automated check written for this flow. It follows the standard scripted path: select a plan, click subscribe once, confirm the subscription appears.

test('a subscription can be purchased end-to-end', async ({ page }) => {
  await page.goto('/demo-subscription.html');

  // add a plan to the cart
  await page.locator('.add-btn[data-plan="Premium"]').click();
  await expect(page.locator('#cart-items .cart-row')).toHaveCount(1);

  // proceed to checkout and fill in the customer details
  await page.locator('#proceedBtn').click();
  await page.locator('#name').fill('Anna Muster');
  await page.locator('#email').fill('anna@example.com');
  await page.locator('#confirmBtn').click();

  // order is confirmed with the correct total
  await expect(page.locator('.confirm-box .big')).toContainText('Thank you');
  await expect(page.locator('#done-total')).toHaveText('CHF 19.90');
});

This test passes, the entire journey works: plan added, checkout reached, order confirmed, total correct. And that's exactly the problem with relying on it alone: it clicks "Add subscription" precisely once, because that's what it was scripted to do. It never asks "what if the user clicks twice?"

Reveal the bug

The "Add subscription" button has no debounce and isn't disabled while the simulated server call is running. Click it twice quickly and the same subscription lands in the cart twice, and checkout happily confirms the order with a doubled monthly total. In a real system, that's a duplicate charge on the customer's card.

3. The bug report

This is how it would be logged in a real workflow, the same structure used for the QA test documentation sample.

BUG-DEMO-01 · Component: Checkout / SubscriptionHigh

Found by

Exploratory testing, not part of the scripted test plan

Steps to reproduce

1. Open the subscription demo
2. Click "Add subscription" on any plan twice in quick succession (well within a second)
3. Proceed to Checkout, fill in name/email, confirm the order

Expected

One subscription in the cart (button disabled while processing), and an order total of one monthly fee.

Actual

The cart contains the same plan twice, checkout shows a doubled total, and the order is confirmed for both, a single user action results in a double charge.

Root cause

No disabled state or debounce on the submit handler while the simulated request is in flight.

Business impact

In a real payment flow, this is a duplicate charge, a billing dispute and a support ticket, not just a UI glitch.

Why automation missed it

The scripted test only performs a single click, because that's what it was written to do. Nobody wrote a test for impatient double-clicking, a tester exploring the page naturally did.

4. The point

This isn't an argument against automation, the suite in the automated testing sample is exactly the kind of regression safety net every product needs. The point is narrower and, I think, more useful: automated tests confirm what you already thought to check. Manual and exploratory testing finds what you didn't. The strongest QA process uses both, automation for coverage and speed, a human for judgment and curiosity.