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 Module 4 by defining testing boundaries.
The problem: limited QA time
Salesforce is a mature, enterprise-grade platform.
It already guarantees:
- database consistency
- core security enforcement
- UI rendering
- API stability
As QA, we cannot test everything — and we shouldn’t try.
The real skill of a Salesforce QA is knowing:
What can be trusted to the platform, and what must always be verified because humans configured it.
Testing the wrong things wastes time and still lets critical defects escape to production.
The trust vs test framework
All Salesforce behavior falls into one of two categories:
- Trusted platform features — do not test
- Configurable logic — must test
This distinction should drive every test plan.
Trusted platform features (do not test)
These are core, non-configurable Salesforce behaviors.
They are stable, regression-tested by Salesforce, and consistent across orgs.
| Platform feature | Why it can be trusted | Example of what not to test |
|---|---|---|
| Database integrity | Salesforce guarantees atomic transactions and referential integrity | Do not test that a standard Roll-Up Summary correctly sums numbers |
| Core UI rendering | Lightning framework handles layout, responsiveness, and controls | Do not test that the standard Save button works |
| Native security engine | OWD, Profiles, Permission Sets are platform-enforced | Do not test that a user without “Manage Users” cannot access Setup |
| Standard APIs | Core REST/SOAP APIs are stable and versioned | Do not test that login returns a session token |
These features may be used in tests — but they are not the subject of testing.
Configurable logic (must test)
These areas are high-risk because:
- humans configure them
- logic changes frequently
- small mistakes have large impact
| Area | Why it must be tested | Primary QA focus |
|---|---|---|
| Custom data validation | Enforced via Validation Rules or Apex | Boundary values, negative paths |
| Field-Level Security | Defined by Profiles and Permission Sets | Denial of access (not visibility) |
| Automation (Flow / Apex) | Custom logic, order of execution, bulk risk | Entry conditions, paths, limits |
| Integrations | Custom mapping and error handling | Retry logic, consistency, failures |
| Sharing rules | Manually defined visibility logic | Inclusion and exclusion paths |
If logic was configured, coded, or mapped, it must be tested.
Practical QA strategies
Apply the 80/20 rule
Allocate testing effort intentionally:
- 40% — custom code (Apex, LWC)
- 40% — declarative logic (Flows, Validation Rules, Sharing Rules)
- 20% — platform smoke coverage
If most effort goes into clicking UI paths, QA value is low.
Focus on metadata dependencies
When a configuration change is introduced, defects rarely exist in isolation.
Example: adding a new Record Type.
QA must immediately identify dependencies:
- Flows referencing the Record Type
- Validation Rules checking Record Type
- Page Layouts and Picklist restrictions
- Sharing Rules scoped by Record Type
Testing only the new Record Type itself is insufficient.
Summary: trust the platform, test the customization
Effective Salesforce QA is not about testing everything.
It is about:
- trusting the platform where it is stable
- aggressively testing where humans introduced logic
- focusing effort on risk, not coverage
Trust
- core Salesforce engine
- standard UI
- native security framework
Test
- everything configured on top of it
This mindset is what separates Salesforce QA from generic manual testing.
Salesforce rarely breaks itself.
People break Salesforce — and that’s what QA is for.