{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreic7s7l7dnj6ubmy3uuwgh4ufbylhj5qivdhgjepnyg2rfmjt5pzeq",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mopkuvoux222"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreialoyiun6ksxwrjgsmoofbjevltzrjdnycj5yqqyb262uko353wgi"
    },
    "mimeType": "image/webp",
    "size": 73082
  },
  "path": "/qawalah/the-tester-who-had-10-certifications-but-couldnt-write-a-single-test-that-caught-a-bug-1c05",
  "publishedAt": "2026-06-20T09:29:18.000Z",
  "site": "https://dev.to",
  "tags": [
    "testing",
    "playwright",
    "ai",
    "automation",
    "@playwright"
  ],
  "textContent": "You have ISTQB Foundation. ISTQB Advanced. Certified ScrumMaster. A cloud cert. A security testing cert. Maybe a Python for Testers badge from a platform.\n\nAnd you still cannot write a test that finds a real bug.\n\nI 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.\"\n\nThen I asked: \"Show me one test you wrote that caught something the developer missed.\"\n\nSilence.\n\nNot 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.\n\nThat is the difference between a certification holder and a tester.\n\n**Certifications test your memory. Bugs test your thinking.**\n\nLet me show you what I mean.\n\n##  The Certification Trap\n\nCertifications 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.\n\nBut they do not teach you how to find bugs.\n\nHere 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.\n\nThen 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.\n\nNo certification prepares you for that.\n\nThe 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.\n\nThe 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.\n\n##  What a Real Bug-Finding Test Looks Like\n\nLet me show you the difference in code.\n\nHere is a typical test written by someone who studied for certifications but never learned to hunt bugs:\n\n\n\n    import { test, expect } from '@playwright/test';\n\n    test('user can complete checkout with valid credit card', async ({ page }) => {\n      await page.goto('/products');\n      await page.click('[data-test=\"add-to-cart\"]');\n      await page.click('[data-test=\"checkout\"]');\n      await page.fill('[data-test=\"card-number\"]', '4111111111111111');\n      await page.fill('[data-test=\"expiry\"]', '12/28');\n      await page.fill('[data-test=\"cvc\"]', '123');\n      await page.click('[data-test=\"submit-payment\"]');\n      await expect(page.locator('[data-test=\"order-confirmation\"]')).toBeVisible();\n    });\n\n\nThis test passes. It covers the happy path. It proves the feature works when everything is perfect.\n\nIt will never find a bug.\n\nNow here is a test written by someone who thinks like a bug hunter:\n\n\n\n    import { test, expect } from '@playwright/test';\n\n    test('checkout rejects card number with typo in first digit', async ({ page }) => {\n      await page.goto('/products');\n      await page.click('[data-test=\"add-to-cart\"]');\n      await page.click('[data-test=\"checkout\"]');\n\n      // Card number with first digit changed from 4 to 5\n      await page.fill('[data-test=\"card-number\"]', '5111111111111111');\n      await page.fill('[data-test=\"expiry\"]', '12/28');\n      await page.fill('[data-test=\"cvc\"]', '123');\n      await page.click('[data-test=\"submit-payment\"]');\n\n      // The application should reject this card\n      // But does it show an error, or does it silently fail?\n      await expect(page.locator('[data-test=\"error-message\"]')).toBeVisible();\n\n      // Also check: did the order confirmation accidentally appear anyway?\n      const confirmationCount = await page.locator('[data-test=\"order-confirmation\"]').count();\n      expect(confirmationCount).toBe(0);\n    });\n\n\nThe 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.\n\nThis is the mindset. Not \"does it work?\" but \"where does it break?\"\n\n##  The Real Gap: You Have Never Failed a Test\n\nHere 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.\n\nYou 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.\n\nBut you have never written a test that failed because you found a real, previously unknown defect in the application logic.\n\nThat is your career gap. Not a gap in your resume. A gap in your experience.\n\nAnd no certification can fill it.\n\n##  How to Close the Gap\n\nYou close it by writing tests that are designed to fail.\n\nNot flaky tests. Not tests that fail because of timing. Tests that fail because the application has a bug.\n\nHere 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.\n\nFor 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.\"\n\nFor 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.\"\n\nWrite 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.\n\n##  The Code That Changed My Mind\n\nI 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.\n\nThen 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.\n\nThe 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.\n\nOur 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.\n\nAfter 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?\"\n\nHere is a Python example of that mindset:\n\n\n\n    import pytest\n    from decimal import Decimal\n\n    def test_rounding_does_not_favor_any_party():\n        \"\"\"Verify that rounding is consistent between customer and merchant.\"\"\"\n        amounts = [\n            Decimal(\"10.005\"),\n            Decimal(\"19.995\"),\n            Decimal(\"100.005\"),\n            Decimal(\"0.015\"),\n        ]\n\n        for amount in amounts:\n            customer_charge = round_to_cents(amount, party=\"customer\")\n            merchant_payout = round_to_cents(amount, party=\"merchant\")\n\n            # The total should be the same regardless of who we round for\n            assert customer_charge == merchant_payout, (\n                f\"Rounding mismatch for {amount}: \"\n                f\"customer pays {customer_charge}, merchant gets {merchant_payout}\"\n            )\n\n\nThis 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.\n\nThat 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.\n\n##  What to Do This Week\n\nYou have the certs. You have the years. You do not have the proof.\n\nHere is one action. Do not build a portfolio site. Do not update your LinkedIn. Do not study for another certification.\n\nWrite one test that is designed to fail. Not a test that verifies something works. A test that tries to prove something is broken.\n\nRun 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.\n\nWrite 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.\n\nThe next time someone asks you to show them a test that caught a bug, you will have an answer.\n\nNot a certification. An answer.\n\nWhat is the one test you would write this week to prove you can find bugs?",
  "title": "The Tester Who Had 10 Certifications But Couldn't Write a Single Test That Caught a Bug"
}