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.

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:

1. Data Model
2. Security Settings
3. Declarative Logic
4. Apex Logic
5. 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