03.01.02 — Test Case Structure in Salesforce: Goals, Preconditions, Steps
Lesson goal
This lesson explains how a Salesforce test case should be structured and, more importantly, why each section exists.
After this lesson, you should understand:
- which parts of a test case carry most of the analytical value,
- which parts are often overemphasised,
- and how proper structure protects test cases from becoming obsolete as Salesforce implementations evolve.
Why Salesforce test cases need structure
In many projects, test cases are treated as a simple execution checklist:
- click here
- fill this field
- verify a message
This approach fails in Salesforce projects because:
- behaviour is configuration-driven,
- permissions affect outcomes,
- data relationships influence logic,
- Automation can change execution paths.
A Salesforce test case must therefore explain context before execution.
Structure is not about documentation aesthetics.
It is about controlling assumptions.
The three layers of a Salesforce test case
A well-designed Salesforce test case operates on three layers:
- Intent — why the test exists
- Context — under which conditions it is valid
- Execution — how it is performed
Each layer maps directly to a test case section.
Test Goals — defining intent
The Test Goals section defines the purpose of the test.
It answers the question:
What business or system behavior is this test validating?
Which is directly linked to the What? question on the analysis phase.
This section is:
- read first,
- often read by non-QA stakeholders,
- critical during reviews and prioritisation.
A good Test Goal:
- focuses on behaviour, not UI,
- avoids step descriptions,
- remains valid even if implementation changes.
Example
Poor Test Goal:
Verify Opportunity creation flow
Effective Test Goal:
Verify that a Sales Representative can create an Opportunity only for Accounts assigned to their territory
The second example:
- defines business rules,
- implies permission and data constraints,
- guides future maintenance.
Preconditions — defining execution context
Preconditions describe everything that must be true before execution starts.
In Salesforce, Preconditions have the highest analytical value within the test case.
They prevent hidden assumptions from leaking into execution.
Preconditions are usually divided into:
- Users
- Data
Users — defining permission context, not people
A common mistake is defining users as named individuals:
- “Test User 1”
- “John from Sales”
This approach breaks test repeatability.
In Salesforce, a user represents:
- profile
- permission sets
- role
- sharing context
- custom permissions
A correct user definition describes access capabilities, not identity.
Example
Incorrect:
User: Test User 1
Correct:
User: Sales Representative with standard Sales profile and no additional permission sets
This is directly linked to the Who? question from the analysis.
This definition remains valid even if:
- users change,
- environments differ,
- sandboxes are refreshed.
Data — defining structure and state
Test data definitions should describe:
- required objects and records,
- relationships between records,
- record states relevant for the test.
Data should not describe:
- how records were created,
- UI shortcuts,
- implementation-specific IDs.
Example
Poor data definition:
Account and Opportunity exist
Effective data definition:
Account with assigned territory and at least one open Opportunity in Stage = Qualification
This is directly linked to the When? question from analysis.
This level of detail:
- clarifies assumptions,
- supports dry runs,
- improves defect diagnosis.
Why Preconditions matter more than steps
In Salesforce projects:
- steps change frequently,
- UI labels evolve,
- layouts and navigation shift.
Preconditions change far less often.
A test case with strong Preconditions can survive:
- UI refactoring,
- layout changes,
- minor automation updates.
A test case without strong Preconditions becomes obsolete quickly.
High-Level Steps — outlining the flow
High-Level Steps describe what happens, not how to click.
They provide:
- a quick overview of test flow,
- a checklist for reviewers,
- a navigation aid for experienced testers.
High-Level Steps should:
- be short,
- describe logical actions,
- remain stable across UI changes.
Example of High-Level Steps:
- Login as User#1
- Open Opportunity#1 and click on Edit
- Delete Value in Next Stage field
- Verify that the Opportunity record cannot be saved
- Relogin as User#2
- Open Opportunity and click on Edit
- Delete Value in Next Stage field
- Verify that Opportunity #1 record can be saved
There are indications regarding User and Record. Those will be described in details in Test Preconditions section.
Detailed Steps and Expected Results — controlled execution
Detailed Steps describe how execution happens.
Each step should:
- perform a single action,
- have a single corresponding expected result.
Expected Results should:
- validate business logic,
- confirm system behaviour,
- Avoid obvious UI confirmations.
This separation allows:
- clearer execution,
- easier maintenance,
- more precise defect reporting.
Example of full test steps:
| Test Step | Expected Results; |
|---|---|
| Login to SFDC as User#1 | User logged in properly |
| Open Opportunity#1 record and click on Edit | Edit Opportunity page appears |
|
Delete value in Next Stage field Attach Screenshot |
Data deleted Screenshot Attached |
|
Click on Save and verify that record wont be saved Attach Screenshot |
Error message appears above Nest Stage field Screenshot Attached |
| Log out and Login as User#2 | User logged in properly |
| Open Opportunity#1 record and click on Edit | Edit Opportunity page appears |
|
Delete value in Next Stage field Attach Screenshot |
Data deleted Screenshot Attached |
|
Click on Save and verify that record will be saved Attach Screenshot |
Changes were saved Screenshot attached |
Tips — optional but powerful
The Tips section is optional but highly effective.
It can include:
- environment-specific notes,
- known limitations,
- data preparation shortcuts,
- execution hints for experienced testers.
- Data files for import
- SOQL queries to be used during executions
Tips should:
- never replace Preconditions,
- never introduce new requirements,
- never be mandatory for execution.
They exist to reduce friction, not define behavior.
Why this structure scales
This structure allows:
- multiple testers to execute the same test consistently,
- business stakeholders to understand intent,
- teams to review quality effectively,
- test suites to evolve with the system.
Most importantly, it separates:
- intent,
- context,
- execution.
This separation is what makes Salesforce test documentation maintainable.
Key takeaway
A Salesforce test case is not a list of steps.
It is a structured artifact that:
- explains why a test exists,
- defines under which conditions it is valid,
- controls how execution is performed.
Without this structure, even detailed test cases quickly lose their value.