01.05 - Foundations of Salesforce QA
0105 - Test Levels & Testing Quadrants in Salesforce
Free Preview — 01.05: Test Levels & Testing Quadrants in Salesforce
Classic ISTQB testing levels don’t align well with Salesforce — the platform simply behaves differently.
This lesson explains the three practical testing levels used by real Salesforce QA teams, combined with a modern quadrant model adapted for metadata-driven architecture.
If you want to test both faster and deeper, this hybrid approach will become your new blueprint.
Continue reading → (paid content below)
1. Introduction
Salesforce is not a traditional application — therefore, traditional software testing models (unit → integration → system → UAT) often fail to accurately describe what testers really do on Salesforce projects.
To address this, we combine two frameworks:
Salesforce‑specific testing levels (practical, real‑world layers used by Salesforce QA Consultants)
Adapted Agile Testing Quadrants (based on Lisa Crispin’s model, adjusted for metadata‑driven architecture)
Together, they form a powerful, modern approach to planning and executing manual testing in Salesforce projects.
This lesson explains:
how the three Salesforce test levels work
how quadrants help structure your testing purpose
when to apply each testing style
how to mix speed and depth effectively
how to adapt to different project types
---
2. The Three Practical Salesforce Testing Levels
Traditional ISTQB levels (unit, integration, system) do not map well to Salesforce because:
testers cannot influence or test the platform itself
developers test Apex internally
much of the “system integration” is declarative
many features cross multiple objects and processes
Instead, Salesforce QA uses a three‑level practical model:
---
2.1 Level 1 — Core Platform & Setup Verification
(The metadata check: fields, permissions, layouts, visibility, and technical setup)
This level answers the question:
“Has the configuration been implemented correctly?”
Tests include:
field settings (required, default values, types)
validation rules behaviour
profiles & permission sets
FLS for each actor
page layouts & Lightning pages
basic flows execution paths
record creation/edit/delete edge cases
Purpose
Ensure the foundation of the feature works before functional testing begins.
Why it matters
Many UAT blockers come from configuration issues such as:
fields missing on layouts
validation rules not adjusted
wrong profiles lacking CRUD/FLS
automation failing due to missing permissions
Level 1 prevents wasting time on deeper testing when the basics don’t work.
---
2.2 Level 2 — Functional Testing per Requirement
(Testing the requirement as described in the user story)
These tests:
validate all acceptance criteria
confirm workflows and logic
verify automation
use tools like Postman, Salesforce Inspector, and Workbench
require deeper analysis of data conditions
Purpose
Validate that each requirement works in isolation.
Why it matters
Many testers jump straight to end‑to‑end testing and waste enormous time investigating failures caused by a single requirement not functioning correctly.
Level 2 ensures every component behaves predictably before integration into larger flows.
---
2.3 Level 3 — End‑to‑End Business Process Testing
(Simulating realistic user flows across multiple objects and actors)
Examples:
Lead → Opportunity → Quote → Order
Case creation → routing → escalation → resolution
Customer onboarding workflows
Renewal or contract lifecycle processes
These tests verify:
cross‑object logic
multi‑step automation
role‑specific behaviour
data dependencies
timing and async processing
real business workflows
Purpose
Validate that the business can operate the system correctly.
Why it matters
Even when requirements work individually, they may conflict in end‑to‑end context.
Level 3 uncovers the issues that business users will actually encounter.
---
3. Why These Levels Work Better Than Traditional Ones
Salesforce levels align with how the platform behaves — not with how software theory describes testing.
---
4. The Adapted Agile Testing Quadrants
The Agile Testing Quadrants categorize tests along two axes:
Business‑facing vs Technology‑facing
Supporting the team vs Critiquing the product
We adapt this framework to Salesforce, resulting in:
---
4.1 Quadrant 1 — Technology‑Facing Tests Supporting the Team
(Fast, tool‑based checks of configuration and metadata)
Examples:
verifying CRUD/FLS with Inspector
validating field behaviour
checking automation firing conditions
Postman‑based validation of API behaviours
checking execution order (Flow vs Apex)
Purpose
Catch low‑level issues quickly before deeper testing.
Salesforce‑specific aspect
These tests often use:
Salesforce Inspector
Workbench
Postman
Developer Console logs
Instead of UI clicking.
---
4.2 Quadrant 2 — Business‑Facing Tests Supporting the Team
(Tests that validate business intent and prepare for UAT)
Examples:
executing high‑level scenarios defined in acceptance criteria
validating end‑user workflows
verifying that changes support business context
Purpose
Ensure user stories deliver real functional value.
Where it fits
Typically maps to Level 2 + early Level 3.
---
4.3 Quadrant 3 — Business‑Facing Tests Critiquing the Product
(Exploratory tests simulating real user behaviour without shortcuts)
These tests:
aim to break assumptions
follow unexpected paths
use realistic or messy data
replicate how business users actually operate the system
Purpose
Reveal hidden defects not described in requirements.
Example
A Sales Rep tries to convert a Lead with incomplete data → does the system fail gracefully?
---
4.4 Quadrant 4 — Technology‑Facing Tests Critiquing the Product
(Stress, scalability, negative testing, governor limit awareness)
Examples:
bulk testing Opportunity updates (200 records)
trying unusual combinations of inputs
deliberate attempts to break flows or Apex
spike tests for async automation
limit testing (SOQL/DML constraints)
Purpose
Reveal risky technical behaviour that business‑facing tests will never expose.
Why important in Salesforce?
Platform‑enforced limits (Governor Limits) create unique negative scenarios.
---
5. Combining Test Levels with Quadrants: A Practical Strategy
This hybrid model allows testers to:
test fast where needed (Quadrant 1 / Level 1)
test deep where needed (Quadrants 3–4 / Level 3)
test with business value in mind (Quadrant 2)
test technical risks proactively (Quadrant 4)
Example strategy
Start here → Level 1 / Quadrant 1
Verify setup with tools.
Then → Level 2 / Quadrant 2
Verify requirement functionality.
Then → Level 3 / Quadrant 3
Execute realistic flows.
Finally → Quadrant 4
Attack technical weak points.
This approach saves enormous time and aligns with Salesforce’s multi‑layered architecture.
---
6. Summary
Salesforce testers cannot rely on traditional test levels. The platform demands:
fast metadata verification
functional validation per requirement
end‑to‑end testing across personas
exploratory evaluation of real‑world use
technical stress and negative‑path testing
The Three Salesforce Levels + Four Testing Quadrants together form a complete, flexible strategy that supports:
speed
accuracy
risk‑based prioritization
value delivery
efficient communication with the whole team
This hybrid framework is one of the key differentiators between “someone who can click test cases” and a true Salesforce QA Consultant.
---
End of Lesson 01.05