Salesforce Bugs Rarely Live Where You Look Most Salesforce defects are invisible to the naked eye. Learn why the real bugs hide in automation chains, permission layers, and system behavior, not on the screen.
Configuration vs Code: Why Salesforce Testers Must Think in Layers Why two features that look identical almost never behave the same. Early in my Salesforce career, a developer once told me: „Don’t worry, it works the same way whether it’s built in Flow or Apex.” That sentence cost us three days of debugging. Because in Salesforce, how something
Why Salesforce QA Is Not the Same as Manual Testing? A short story about learning a platform that refuses to behave like normal software. When I started working as a Salesforce tester, I was convinced I understood what I was getting into. Testing is testing — you click, compare expected vs actual, and report bugs. A normal job, just with Salesforce
The Ticket That Wasn’t a Bug (But Cost 6 Hours Anyway) Some bugs are loud. Some bugs are dramatic. And some bugs… never existed in the first place — but still consume half your day, three people’s sanity, and the last bit of trust the business has in the system. This is a story about the third type. The Defect That
Case Study: When a Missing Validation Rule Cost a Full Sprint Sometimes bugs are complex. Sometimes bugs require deep investigation. And sometimes bugs exist simply because no one asked a basic question: “Should the user even be allowed to save this?” The Setup The client had a strict rule: “Opportunities must have a Contract Start Date before they can be marked
Automation Chaos: Why Flows Break Even When Everything Looks Fine Every Salesforce tester has experienced this moment: A business user raises a ticket saying, “The system is broken.” You open the record, click the same button… And everything works perfectly. Welcome to the wonderful world of Salesforce automation, where things break silently, inconsistently, and only when you’re not looking.
The Invisible Wall: Why Access Testing Is the Superpower of Salesforce QA Because half the bugs in Salesforce are not bugs — they are permissions. If you want to see a Salesforce architect panic, show them a user who can suddenly see a field they shouldn’t. If you want to see a tester panic, show them a bug report that makes no sense because it “works for Admin.” Every Salesforce tester eventually learns: Nothing
Case Study: The 100-Product Opportunity That Hit Governor Limits Some Salesforce bugs are subtle. Some are dramatic. And some are so catastrophic that the platform itself steps in and says: “No. Absolutely not. Stop what you’re doing.” This is a story about the third kind — a real project, a real failure, and a lesson every Salesforce tester must
Case Study: When Process Builder Migration Almost Broke Production This is one of those Salesforce stories that starts innocently… and ends with half the system refusing to work. It’s also one of the best lessons about the difference between Process Builder, Flow, and Apex execution context. Background The client had around 40 Process Builders running various parts of
Why Testers Should Never Test as Admins Every tester has done it at least once. You log in as Admin “just to check one thing.” Five minutes later, everything magically works, the bug disappears, and life seems beautiful. Until you test the same scenario as a real user. And the entire process collapses like a Jenga tower