04.06.02 — Common Salesforce QA Failure Patterns
Lesson goal
This lesson identifies recurring Salesforce QA failure patterns observed across real projects and explains how to defend against them proactively.
After completing this lesson, you should be able to:
- recognize high-risk QA blind spots early
- anticipate failures before they reach production
- apply defensive test strategies instead of reactive bug hunting
- classify defects using architectural patterns, not symptoms
This lesson closes Module 4 by shifting QA thinking from execution to risk prevention.
The problem: repeating the mistakes of others
Salesforce projects fail in predictable ways.
Not because teams are careless — but because:
- Salesforce has a layered architecture
- many failures only appear at scale
- UI-based testing hides systemic risks
The same defect types reappear across projects:
- bulk failures
- hidden security leaks
- automation collisions
- integration instability
A senior Salesforce QA does not wait to discover these bugs.
They expect them and design tests accordingly.
High-risk Salesforce QA failure categories
Most QA failures in Salesforce fall into three architectural categories:
- Data integrity & modeling
- Security & access control
- Automation & integration
Understanding these patterns allows QA to test where failure is likely, not where it is easy.
1. Data integrity and data model failures
These failures break data consistency or corrupt relationships between records.
| Failure pattern | Description | Defensive QA strategy |
|---|---|---|
| Missing bulkification test | Testing only single-record operations and missing limit failures during bulk updates | Always run 200-record DML tests on automated and integrated objects |
| Incomplete deletion testing | Verifying parent deletion without validating child record behavior | Test cascading delete (Master-Detail) and lookup nullification explicitly |
| Record Type exclusion | Testing logic only on the primary Record Type | Always include a control Record Type and verify logic does not execute |
QA mindset:
If the platform supports multiple records, assume bulk execution.
2. Security and access control failures
These failures expose data unintentionally due to misunderstood security layering.
| Failure pattern | Description | Defensive QA strategy |
|---|---|---|
| The FLS illusion | Trusting UI visibility instead of enforcing FLS | Bypass UI using Data Loader to validate field access |
| Read allowed, update denied | Testing record visibility but not save permissions | Always test Read vs Update separately |
| Permission Set conflict | Assuming Profile restrictions override Permission Sets | Test the most permissive rule explicitly |
QA mindset:
If access is layered, test denial paths more than success paths.
3. Automation and integration failures
These failures occur at scale, over time, or under unexpected conditions.
| Failure pattern | Description | Defensive QA strategy |
|---|---|---|
| Flow decision blind spot | Missing boundary values in decision logic | Apply BVA + EP to every Flow decision |
| Integration retry loop | Retry mechanism never exits on fatal error | Test maximum retry exhaustion and admin notification |
| Order of execution collision | Automation overwrites itself due to execution order | Validate final field state, not intermediate steps |
QA mindset:
Automation rarely fails once — it fails repeatedly and silently.
Practical defensive QA techniques
Use a pre-test risk checklist
Before executing tests, ask:
- Does this touch DML?
→ Have I planned a bulk test? - Does this change visibility?
→ Have I planned a denial test? - Does this call an external system?
→ Have I planned a failure and retry test?
If the answer is “no”, the test is incomplete.
Classify bugs by failure pattern
When a defect is found, classify it deliberately:
- “Missing bulkification coverage”
- “Record Type exclusion failure”
- “FLS vs UI illusion”
This:
- improves root cause analysis
- educates the team
- prevents the same bug category from reappearing
QA maturity grows when patterns are named and reused.
Summary: defensive QA beats reactive QA
Salesforce QA failures are rarely random.
They follow architectural patterns related to:
- bulk processing
- security layering
- automation order
- integration resilience
By recognizing these patterns early and embedding them into test design, QA evolves from:
finding bugs
to
preventing production incidents
Great Salesforce QA is not about testing more.
It’s about testing where failure is inevitable.