04.03.02 — Testing Automation Without Reading Code
Lesson goal
This lesson explains how QA can safely and effectively test Apex-based automation without reading Apex code.
After completing this lesson, you should be able to:
- apply black-box testing techniques to Apex Triggers and Classes
- design test cases based on inputs, outputs, and side effects
- identify logic defects, performance issues, and rollback failures
- collaborate with developers without becoming dependent on code reviews
This lesson extends Flow testing principles to custom code and completes the automation testing foundation in Module 4.
The problem: black-box QA in a custom code world
Salesforce automation is not limited to declarative tools like Flows.
Critical business logic is often implemented using:
- Apex Triggers
- Apex Classes
- custom services and integrations
From a QA perspective, reading Apex code is:
- time-consuming
- error-prone
- often unrealistic in large projects
Fortunately, reading the code is not required to test its behavior correctly.
QA validates what the system does, not how the developer implemented it.
The black-box testing mindset
Black-box testing treats Apex logic as an executable unit:
- inputs go in
- outputs and side effects come out
The QA goal is to prove that:
- correct inputs produce correct outcomes
- incorrect inputs fail safely
- the system remains stable under load
Business requirements, not source code, define correctness.
Input validation and edge cases
Every Apex-driven process reacts to specific inputs:
- field values
- record state changes
- API payloads
- bulk operations
QA challenges these inputs using classic test design techniques.
Boundary Value Analysis (BVA)
Use BVA for numeric and date-based logic.
Example scenario:
- Apex applies a 15% discount when Opportunity Amount ≥ 50,000
Test cases:
- Amount = 49,999 → no discount
- Amount = 50,000 → discount applied
- Amount = 50,001 → discount applied
This validates operator correctness and boundary handling.
Equivalence Partitioning (EP)
Use EP for categorical inputs such as picklists or statuses.
Example:
- Apex sends notifications based on
Account.Region__c
Test focus:
- test one value per valid region
- test null or invalid region value
- verify default or fallback behavior
Side effect verification
Apex logic frequently affects records beyond the trigger source.
QA must explicitly verify all side effects.
Common side effects to test
| Apex behavior | QA verification |
|---|---|
| Roll-up calculations | Query parent records and validate aggregates |
| Cross-object updates | Verify related records reflect expected changes |
| Integration callouts | Validate logs, response handling, and stored IDs |
If a side effect is undocumented, it is still part of the test scope.
Negative testing and governor limits
Apex operates under strict Governor Limits.
Black-box testing must prove that the logic:
- is bulk-safe
- handles failures gracefully
- does not leave partial data behind
Bulk operation testing
- Action: Use Data Loader to insert or update 200 records in one transaction
- Expected result:
Operation succeeds without limit exceptions
Failure indicates non-bulkified code — a serious quality defect.
Exception handling and rollback
Test conditions that should fail safely.
Example:
- invalid input format
- missing required data
- integration timeout
Expected result:
- user-friendly error
- full transaction rollback
- no partial data saved
Practical QA collaboration strategies
Trigger-to-requirement mapping
QA should maintain a simple mapping:
- business requirement → Apex component
This allows:
- focused test coverage
- traceability without code inspection
- faster regression testing
If a requirement changes, associated Apex behavior can be retested immediately.
Using debug logs without reading code
QA can use Debug Logs without understanding Apex syntax.
What to verify:
- execution path reached expected checkpoints
- number of SOQL queries and DML operations
- absence of limit warnings
Debug Logs expose performance and logic flaws invisible in the UI.
Summary
QA does not need to read Apex code to test it effectively.
By applying black-box testing techniques, QA can:
- validate business behavior
- detect boundary and logic defects
- identify performance and governor limit risks
- ensure safe rollback on failure
Focusing on inputs, outputs, and side effects allows QA to test complex automation confidently while remaining independent of implementation details.
What’s next
In the next lesson, we focus on failure paths and defensive automation design:
04.03.03 — Fault Paths, Error Handling, and Safe Automation Design