04.06.03 — From Modules to Real Projects

Lesson goal

This lesson explains how to apply Modules 04.01–04.06 in real Salesforce projects.

After completing this lesson, you should be able to:

• translate technical QA modules into a practical test plan
• prioritize testing based on risk, not module order
• design integrated test cases that validate multiple risk areas at once
• classify defects by architectural root cause, not surface symptoms

This lesson closes Module 04 and prepares you for full, end-to-end project testing in Module 05.

The problem: knowing everything, testing nothing

By this point, you understand:

• data models and relationships
• security layering
• automation (Flows, Apex)
• integrations and performance constraints
• Governor Limits and bulk behavior

The challenge is no longer what to test —
it is how to combine everything into a coherent strategy.

Real Salesforce projects never change just one thing.
They introduce interacting risks.

QA fails when testing remains:

• modular
• isolated
• checklist-driven

QA succeeds when testing becomes synthetic and risk-based.

The synthesis framework: risk-based test planning

We use the Risk Matrix introduced in Module 03 to decide:

• what to test first
• what to test together
• what can safely wait

Step 1: pre-analysis and risk mapping

Before writing test cases, identify what actually changed.

1. Change type identification

Example project change:

“Introduce a new custom object Contract_Amendment__c with an approval process and SAP integration.”

This single change impacts:

• Data Model (new object, relationships)
• Security (new object permissions, sharing rules)
• Automation (approval process, flows)
• Integration (outbound sync to SAP)
• Performance (bulk amendments)

This is not one test area — it is five.

2. Risk prioritization

Prioritize testing based on impact and irreversibility, not convenience.

Example priority order:

• P1 — Security & Integration
  Execute 04.02 and 04.04 first
  (data exposure and external sync are highest risk)
• P2 — Automation & Performance
  Execute 04.03 and 04.05 next
  (approvals, limits, recursion)
• P3 — Data Model
  Execute 04.01 last
  (CRUD and relationship validation)

Order is strategic — not academic.

Step 2: integrated test case design

Real Salesforce test cases validate multiple modules simultaneously.

Combined modules	What must be verified	Example integrated test
Security + Automation	Permissions and logic execution	As Sales Rep, submit Opportunity for approval. Verify record locks and restricted user cannot view it.
Integration + Performance	Data consistency under load	Bulk update 50 Accounts via Data Loader. Verify ERP sync succeeds and no limit errors occur.
Data Model + Automation	Relationship behavior and side effects	Delete parent Account. Verify child records cascade and audit Flow executes correctly.

This is how production failures actually surface.

Step 3: execution and defect classification

During execution, classify defects by architecture, not by symptom.

Example:

• Symptom: “Error occurs when saving 20 Leads”
• Wrong classification: “Flow bug”
• Correct classification:
  04.05.02 — Missing bulkification

This classification:

• speeds up developer fixes
• prevents repeat failures
• improves long-term quality

Practical go-live strategies

The go-live regression checklist

Before any release:

• Security regression:
  Re-run CRUD + Sharing Rule tests for the most restricted role
• Performance regression:
  Re-run at least one 200-record bulk test on critical objects
• Integration regression:
  Test success path and failure path for every external endpoint

If any of these fail, the release is not ready.

Salesforce release awareness

Salesforce releases three major updates per year.

Even without custom changes:

• Flow engine behavior can change
• Lightning UI can regress
• platform limits may shift subtly

QA strategy:

• run focused regression after each Salesforce release
• prioritize areas touched by release notes
• never assume “platform = safe” without verification

Summary: the technical Salesforce QA expert

At senior level, Salesforce QA is not about:

• executing test cases
• validating screens
• clicking happy paths

It is about:

• synthesizing risk
• understanding architectural interaction
• testing where failure is most expensive

By combining:

• Data Model
• Security
• Automation
• Integrations
• Performance

into a single, risk-based strategy, QA ensures the system is not only functional — but secure, scalable, and production-ready.

Modules teach knowledge.
Projects demand synthesis.