01.02 - Foundations of Salesforce QA
0102 - What Are We Actually Testing in Salesforce
Free Preview — 01.02: What Are We Actually Testing in Salesforce?
Unlike traditional applications, Salesforce doesn’t allow you to test “everything” — but with the right approach, you can get surprisingly close.
This lesson breaks down what Salesforce testing really means and how requirement categorization unlocks deeper, more accurate analysis.
You’ll discover how to transform vague requirements into clear, structured test objectives.
Continue reading → (paid content below)
1. Introduction
A common misconception across Salesforce projects — especially among people new to the platform — is that testing is “lighter” or “simpler” because so much of Salesforce is standardized, pre‑built, or declaratively managed.
This is not true.
Salesforce testing is fundamentally different because:
you never test the platform
you always test the solution built on the platform
every change interacts with existing metadata, automation, user permissions, and UI
behaviour varies by actor, profile, and record context
almost everything is interconnected
To test effectively, you must understand what exactly can be changed in Salesforce, and therefore — what must be tested. This lesson outlines the five categories of platform elements that define the full scope of Salesforce QA.
---
2. The Core Principle: You Cannot Test Everything — But You Can Get Close
Salesforce is vast. A single org may contain:
dozens of custom objects
hundreds of fields
hundreds of permission set assignments
dozens of flows
multiple Apex classes
complex security rules
deep UI customization
Testing every possible variant of every scenario is impossible.
But with the right fundamentals, you can reliably test everything that matters — the parts of the system where:
data can break
logic can misfire
permissions can block access
automations can collide
record relationships can fail
UI can mislead or misbehave
To achieve this, Salesforce testers categorize system behaviour into well‑defined requirement types.
---
3. The Five Categories of What We Test in Salesforce
Every requirement — regardless of project, cloud, industry, or team — fits into one of the categories below.
Understanding them is the foundation of all test analysis.
---
3.1 Data Model
The Data Model defines what data can exist in the system and how it is structured. Changes here are highly visible and usually easy to identify.
Typical data model changes include:
creating or modifying fields
changing field type or default values
updating validation rules
creating or adjusting field sets
modifying picklists
adjusting relationship definitions
Why test it?
Because everything else in Salesforce depends on the data model.
A single incorrect field configuration can:
block record creation
break automation
hide important data from the UI
cause integration failures
create inconsistent datasets
Even a “small, technical field for API only” introduces new test conditions:
does it sync correctly?
is it hidden from all UI actors?
is it editable only through integrations?
These “little things” break production more often than large features.
---
3.2 Security Settings
Security is one of the most critical — and most misunderstood — areas in Salesforce testing.
It consists of two distinct layers:
A. Object‑level access
Controlled by:
Profiles
Permission Sets
This determines whether a user can:
create records (C)
read records (R)
update records (U)
delete records (D)
B. Record‑level access
Controlled by:
Organization‑Wide Defaults (OWD)
Role hierarchy
Sharing rules
Manual sharing
Why test it?
Because a perfectly built solution is useless if users cannot access or modify what they need.
Broken security leads to:
blockers during UAT
escalations from business users
production incidents impacting entire departments
Security is the #1 cause of “the system doesn’t work” messages — and testers must know exactly how to verify it.
---
3.3 Declarative Logic
Declarative logic refers to all point‑and‑click automation configurable in Salesforce without writing code:
Validation Rules
Workflow Rules (legacy)
Process Builder (legacy)
Flows (modern standard)
Approval Processes
Assignment Rules
Auto‑response Rules
Escalation Rules
These automations shape business behaviour.
Why test it?
Declarative tools can become extremely complex — especially Flows.
A single flow may:
run several decision branches
update records across multiple objects
trigger subflows
interact with Apex
rely on record values or user permissions
Declarative automation is powerful but fragile.
Testing ensures:
correct logic execution
no unintended updates
correct branching
no infinite loops or recursion errors
stable performance at scale
---
3.4 Apex Logic
Apex enters the picture when declarative tools are not enough.
Typical Apex components include:
Triggers
Classes
Batch jobs
Schedulable jobs
Queueable operations
REST endpoints
Future methods
Custom controllers in LWC
Why test it?
Because Apex operates under platform limitations known as Governor Limits, such as:
CPU time
SOQL query limits
DML operation limits
heap size
callout limits
Even well‑written Apex may:
pass tests for a small dataset but fail at scale
behave differently for different profiles
cause crashes when integrated with flows or PB
silently corrupt data if not validated properly
Testers must understand not how to write code — but how to break it through realistic scenarios and edge cases.
---
3.5 User Interface (UI) Changes
UI testing includes:
Page Layouts
Lightning Pages
Quick Actions
Custom buttons
LWC components
Visibility settings
Dynamic forms
Conditional elements
Why test it?
Because the UI is where users interact with Salesforce.
Testing verifies:
correct field visibility
logical placement of information
intuitive workflows
no duplicated or irrelevant components
proper mobile/desktop behaviour
Even small UI redundancies can significantly degrade user experience.
---
4. Understanding the Testing Scope Through These Categories
Every requirement falls into one or more of the five categories.
Example:
“Add an automated discount calculation on Opportunity.”
Breaks down into:
Data Model → new field “Discount %”
Security → editable by Sales Rep, read‑only for Management
Declarative logic → Flow calculating discount
UI → field placement on Opportunity layout
One business request = at least four distinct testing areas.
This analytical approach structures your testing and prevents gaps.
---
5. The Bigger Picture: Why Categorization Matters
Effective test categorization enables:
clearer requirement analysis
faster creation of test cases
better risk evaluation
identification of hidden conditions
efficient communication with devs and consultants
significantly reduced rework
Bad categorization leads to:
missed edge cases
unpredictable behaviour in production
repeated defects caused by unclear testing scope
This is why module 01 exists — to build a mindset that prevents these issues from the foundation level.
---
6. Summary
Salesforce testing is not about clicking through obvious scenarios.
It is about understanding what types of system elements can change — and how they interact.
Every requirement fits into one or more categories:
Data Model
Security Settings
Declarative Logic
Apex Logic
UI Changes
Mastering these categories allows testers to:
identify all relevant test conditions
detect hidden risks early
communicate precisely with consultants and developers
produce structured, scalable test analysis
avoid overlooking critical behaviours
This is the beginning of truly understanding how Salesforce solutions operate and how to test them effectively.
---
End of Lesson 01.02