04.05.01 — What Governor Limits Mean for QA
Lesson goal
This lesson explains how Salesforce Governor Limits translate into QA responsibilities.
After completing this lesson, you should be able to:
- understand why Governor Limits are QA requirements, not developer trivia
- design test cases that expose bulkification and performance risks
- validate synchronous vs asynchronous execution strategies
- identify scalability defects before they reach production
This lesson opens the Performance & Scalability section of Module 4.
The problem: performance is defined by limits
Salesforce enforces strict Governor Limits on every transaction:
- number of SOQL queries
- number of DML operations
- CPU execution time
- heap size and callout limits
These limits exist because Salesforce is a multi-tenant platform.
From a QA perspective, this means:
A feature that works for one record may completely fail for realistic data volumes.
If QA tests only single-record scenarios, the most dangerous defects remain invisible until production.
How QA should think about Governor Limits
Developers think about Governor Limits while writing code.
QA must think about them while breaking the system.
The QA role is not to optimize code, but to:
- simulate realistic volume
- push execution to platform boundaries
- expose scalability assumptions
Limits define bulkification requirements
The most critical Governor Limits are:
- 100 SOQL queries per transaction
- 150 DML statements per transaction
These limits immediately define whether automation is bulkified or not.
High-volume transaction test
For any object with automation (Flow or Apex):
Test setup
- Use Data Loader
- Perform a single operation on 200 records
Expected results
- Pass: all records are processed successfully
- Fail: system throws
System.LimitException
(e.g. Too many SOQL queries: 101)
A failure here is a high-severity defect.
It means the solution will collapse under normal business usage.
Limits define asynchronous strategy
Some operations cannot safely run synchronously:
- large data imports
- complex integrations
- multi-object processing
These must be handed off to asynchronous execution:
- Queueable Apex
- Batch Apex
- Future methods
Asynchronous handover test
Action
- Trigger a large operation (e.g. import 10,000 records)
QA verification
- the UI action completes quickly
- a background job appears in Apex Jobs
- the job processes records in batches
- no Governor Limits are hit per batch
If a heavy process runs synchronously, it is a design flaw — not a tuning issue.
Limits define user experience (CPU time)
The CPU time limit directly affects:
- save performance
- UI responsiveness
- perceived system stability
UI response time test
Action
- Save a record that triggers multiple automations
(Flows, Roll-Ups, Validation Rules)
Expected result
- save completes within an acceptable business window
- no CPU time limit exception
- no noticeable UI freeze
A transaction that “eventually succeeds” but takes several seconds is already a quality risk.
Practical QA strategies
The “boundary plus one” test
Whenever a requirement assumes a maximum number, QA must test one more.
Example
- requirement assumes max 50 related records
- QA creates 51 and triggers automation
Failures here usually indicate:
- hidden Governor Limit dependency
- incorrect design assumptions
- lack of scalability thinking
Reading Debug Logs as QA
QA does not need to read Apex code — but must read Debug Logs.
Every transaction log contains:
- SOQL usage
- DML usage
- CPU time
QA red flags
- SOQL usage near 100
- DML usage near 150
- CPU time near limit
A test that “passes” but consumes 90% of limits is a latent production failure.
Summary: Governor Limits are QA requirements
Governor Limits define:
- how much data the system can handle
- how automation must be designed
- when asynchronous processing is mandatory
From a QA perspective:
- limits are non-functional requirements
- volume testing is not optional
- single-record tests are insufficient
By actively testing bulk operations, execution boundaries, and performance, QA ensures that Salesforce solutions scale safely — not just functionally.
If you don’t test Governor Limits, production will — under pressure.