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.

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

Traditional Model	Salesforce Reality
Unit tests done by testers	Apex unit tests done by devs
Integration testing on backend	Automation chain = flows + Apex + validation rules
UI testing is separate	UI interacts with security + automation + layouts
Testers validate entire system	Testers validate metadata‑driven behaviour across layers
Requirements map clearly to features	Requirements must be decomposed into categories

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