The Tester Who Had 10 Certifications But Couldn't Write a...

You have ISTQB Foundation. ISTQB Advanced. Certified ScrumMaster. A cloud cert. A security testing cert. Maybe a Python for Testers badge from a platform.

And you still cannot write a test that finds a real bug.

I interviewed someone like you last quarter. The resume was a wall of acronyms. The conversation was a wall of theory. "I follow the V-model." "I use equivalence partitioning." "I believe in shift-left."

Then I asked: "Show me one test you wrote that caught something the developer missed."

Silence.

Not because they were nervous. Because they had never written a test that found a bug. They had written tests that passed. They had written tests that covered requirements. They had never written a test that broke something.

That is the difference between a certification holder and a tester.

Certifications test your memory. Bugs test your thinking.

Let me show you what I mean.

The Certification Trap

Certifications are not useless. They give you vocabulary. They give you structure. They give you something to put on LinkedIn so recruiters stop asking if you know what a test case is.

But they do not teach you how to find bugs.

Here is why. Every certification exam tests known knowledge. You study a syllabus. You memorize definitions. You answer multiple-choice questions about boundary value analysis. You pass.

Then you sit in front of an application. The application does not have a syllabus. It does not have a boundary value analysis section in the documentation. It has a login form that sometimes lets you in with a password that is clearly wrong, but only on Tuesdays, and only if the server clock is behind by exactly four minutes.

No certification prepares you for that.

The tester with 10 certifications treats testing like a checklist. They write test cases from requirements. They execute them. They mark pass or fail. They report coverage metrics.

The tester who finds bugs treats testing like an investigation. They start with a hypothesis. They try to prove the application wrong. They follow the weirdness.

What a Real Bug-Finding Test Looks Like

Let me show you the difference in code.

Here is a typical test written by someone who studied for certifications but never learned to hunt bugs:

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

test('user can complete checkout with valid credit card', async ({ page }) => {
  await page.goto('/products');
  await page.click('[data-test="add-to-cart"]');
  await page.click('[data-test="checkout"]');
  await page.fill('[data-test="card-number"]', '4111111111111111');
  await page.fill('[data-test="expiry"]', '12/28');
  await page.fill('[data-test="cvc"]', '123');
  await page.click('[data-test="submit-payment"]');
  await expect(page.locator('[data-test="order-confirmation"]')).toBeVisible();
});

This test passes. It covers the happy path. It proves the feature works when everything is perfect.

It will never find a bug.

Now here is a test written by someone who thinks like a bug hunter:

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

test('checkout rejects card number with typo in first digit', async ({ page }) => {
  await page.goto('/products');
  await page.click('[data-test="add-to-cart"]');
  await page.click('[data-test="checkout"]');

  // Card number with first digit changed from 4 to 5
  await page.fill('[data-test="card-number"]', '5111111111111111');
  await page.fill('[data-test="expiry"]', '12/28');
  await page.fill('[data-test="cvc"]', '123');
  await page.click('[data-test="submit-payment"]');

  // The application should reject this card
  // But does it show an error, or does it silently fail?
  await expect(page.locator('[data-test="error-message"]')).toBeVisible();

  // Also check: did the order confirmation accidentally appear anyway?
  const confirmationCount = await page.locator('[data-test="order-confirmation"]').count();
  expect(confirmationCount).toBe(0);
});

The second test is not more complex. It is more suspicious. It assumes the application will fail. It checks for the error. It also checks that the success state did not accidentally appear.

This is the mindset. Not "does it work?" but "where does it break?"

The Real Gap: You Have Never Failed a Test

Here is the honest truth for the reader I am speaking to directly. You, the tester with three years of experience and a stack of certs. You have never written a test that failed for a reason you did not expect.

You have seen tests fail because the environment was down. You have seen tests fail because the data changed. You have seen tests fail because someone updated the locator.

But you have never written a test that failed because you found a real, previously unknown defect in the application logic.

That is your career gap. Not a gap in your resume. A gap in your experience.

And no certification can fill it.

How to Close the Gap

You close it by writing tests that are designed to fail.

Not flaky tests. Not tests that fail because of timing. Tests that fail because the application has a bug.

Here is the exercise I give every tester I mentor. Pick one feature in your current application. Spend one hour writing tests that try to break it. Not tests that verify it works. Tests that verify it breaks correctly.

For a search feature, do not test that "search returns results for a valid query." Test that "search returns zero results for gibberish" and "search handles SQL injection characters without crashing" and "search with an empty string shows a helpful message instead of a 500 error."

For a file upload feature, do not test that "user can upload a valid PDF." Test that "uploading a file named ../../../etc/passwd does not overwrite system files" and "uploading a 2GB file shows a size error before the upload starts" and "uploading a file with no extension does not crash the preview generator."

Write these tests. Run them. When they fail, you have found a bug. When they pass, you have proven the application handles edge cases correctly. Either way, you learn something.

The Code That Changed My Mind

I was wrong about something for years. I thought good test automation meant covering every requirement with a passing test. I measured success by green builds.

Then I worked on a payment system for a fintech team. We had 95% test coverage. Every test passed. The system went to production and lost money for three days before anyone noticed.

The bug was in a rounding calculation. When the total was something like $10.005, the system rounded down for the customer but rounded up for the merchant. The difference was pennies per transaction. Over thousands of transactions, it was real money.

Our tests covered the happy path. They covered the sad path. They did not cover the "what if the decimal math is wrong" path because nobody thought to write that test.

After that, I changed how I write tests. Now every test starts with a question: "What would have to be true for this feature to fail silently?"

Here is a Python example of that mindset:

import pytest
from decimal import Decimal

def test_rounding_does_not_favor_any_party():
    """Verify that rounding is consistent between customer and merchant."""
    amounts = [
        Decimal("10.005"),
        Decimal("19.995"),
        Decimal("100.005"),
        Decimal("0.015"),
    ]

    for amount in amounts:
        customer_charge = round_to_cents(amount, party="customer")
        merchant_payout = round_to_cents(amount, party="merchant")

        # The total should be the same regardless of who we round for
        assert customer_charge == merchant_payout, (
            f"Rounding mismatch for {amount}: "
            f"customer pays {customer_charge}, merchant gets {merchant_payout}"
        )

This test found nothing in the first version. The developers had written correct rounding. But when we added a new currency with different decimal places, this test caught the bug in the first hour. It was already written. It was already running. It failed immediately.

That is the value of tests that are designed to find bugs. They sit there, waiting for the code to change, and they catch the regression before it reaches production.

What to Do This Week

You have the certs. You have the years. You do not have the proof.

Here is one action. Do not build a portfolio site. Do not update your LinkedIn. Do not study for another certification.

Write one test that is designed to fail. Not a test that verifies something works. A test that tries to prove something is broken.

Run it. If it passes, you have documented a safety guarantee. If it fails, you have found a bug. Either way, you have something real to show.

Write it up. Three paragraphs. What you tested. How you tested it. What you found. That is your portfolio. That is proof that you can think.

The next time someone asks you to show them a test that caught a bug, you will have an answer.

Not a certification. An answer.

What is the one test you would write this week to prove you can find bugs?

推荐订阅源

DEV Community