Salesforce Tester

Sign in Subscribe

Tomasz Teodorowicz

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

The Myth of the “Quick Fix” in Salesforce Projects

There are few phrases that make Salesforce testers more nervous than: “It’s just a quick fix.” Every time someone says it, a validator breaks, a flow collapses, and somewhere in the distance an Integration Lead feels a disturbance in the Force. Let me tell you why “quick fixes” almost

Five Mistakes Every New Salesforce Tester Makes (I made all of them)

If you're new to Salesforce testing, congratulations: You’re about to learn the rules of a game that looks simple — until you start playing. Here are five mistakes every beginner makes (and that I absolutely made myself). 1. Testing as Admin Classic. Everything works. Then it doesn’t.

04.06.03 — From Modules to Real Projects

Lesson goal This lesson explains how to apply Modules 04.01–04.06 in real Salesforce projects. After completing this lesson, you should be able to: * translate technical QA modules into a practical test plan * prioritize testing based on risk, not module order * design integrated test cases that validate multiple

04.06.02 — Common Salesforce QA Failure Patterns

Lesson goal This lesson identifies recurring Salesforce QA failure patterns observed across real projects and explains how to defend against them proactively. After completing this lesson, you should be able to: * recognize high-risk QA blind spots early * anticipate failures before they reach production * apply defensive test strategies instead of reactive

04.06.01 — What to Test vs What to Trust in Salesforce

Lesson goal This lesson explains how QA should allocate testing effort in Salesforce projects. After completing this lesson, you should be able to: * distinguish platform behavior from custom logic * avoid wasting time testing Salesforce internals * focus QA effort where defects actually occur * design smarter, risk-based test plans This lesson closes

04.05.02 — Testing Bulk Operations and Data Volume

Lesson goal This lesson explains how QA should test Salesforce at scale, not just functionally. After completing this lesson, you should be able to: * design bulk operation test cases (imports, mass updates, deletions) * expose non-bulkified automation and performance bottlenecks * understand data volume and ownership skew risks * validate long-running asynchronous jobs

04.05.01 — What Governor Limits Mean for QA

Lesson goal This lesson explains how Salesforce Governor Limits translate into QA responsibilities. After completing this lesson, you should be able to: * understand why Governor Limits are QA requirements, not developer trivia * design test cases that expose bulkification and performance risks * validate synchronous vs asynchronous execution strategies * identify scalability defects

04.04.03 — Failure Modes in Integrated Environments

Lesson goal This lesson explains how QA should test and document integration failures in Salesforce environments where multiple systems interact asynchronously. After completing this lesson, you should be able to: * identify common integration failure modes * design test cases for partial and asynchronous failures * verify compensating logic and recovery paths * validate

04.04.02 — Testing Data Consistency Across Systems

Lesson goal This lesson explains how QA validates data consistency in integrated Salesforce environments. After completing this lesson, you should be able to: * understand why latency is unavoidable in integrations * test whether synchronization delays are acceptable to the business * verify retry and recovery mechanisms * detect data overwrite and conflict scenarios