03.02.01 — High-Level Steps vs Detailed Steps
Lesson goal
This lesson explains the difference between High-Level Steps and Detailed Steps and shows how to use both effectively in Salesforce test cases.
After this lesson, you should understand:
- why not every test case should start with detailed steps,
- how High-Level Steps improve analysis, reviews, and maintenance,
- and when detailed execution steps are actually required.
Why step granularity matters in Salesforce
In many projects, test cases are written as a flat list of detailed steps.
This creates several problems in Salesforce environments:
- UI changes force frequent rewrites,
- reviewers struggle to understand test intent,
- execution focuses on clicks instead of behaviour.
Step granularity is not a formatting choice.
It is a design decision that directly impacts test quality and maintenance cost.
What High-Level Steps actually are
High-Level Steps describe logical actions, not UI interactions.
They answer the question:
What happens in this part of the process?
Examples of High-Level Steps:
- Authenticate as Sales Representative
- Create a new Opportunity for an existing Account
- Change Opportunity Stage to Closed Won
- Verify pricing and approval behavior
They define flow, not execution mechanics.
What High-Level Steps are not
High-Level Steps are not:
- click-by-click instructions,
- navigation paths,
- UI walkthroughs.
This is a common misunderstanding.
If a step contains:
- button names,
- menu paths,
- screen labels,
it is no longer a High-Level Step.
Why High-Level Steps are critical in Salesforce projects
Salesforce implementations change frequently:
- layouts evolve,
- Lightning components are rearranged,
- flows replace validation rules,
- automation paths are refactored.
High-Level Steps remain stable because they describe business intent, not UI structure.
They allow test cases to survive:
- UI refactoring,
- layout changes,
- minor configuration updates.
High-Level Steps as an analysis tool
High-Level Steps are not only an execution aid.
They are also an analysis artefact.
Writing High-Level Steps forces you to:
- identify the real process flow,
- define meaningful checkpoints,
- separate business actions from technical details.
If you cannot express a test flow in High-Level Steps, the requirements are likely unclear.
Detailed Steps — when execution control is required
Detailed Steps describe how a High-Level Step is executed.
They are required when:
- execution must be repeatable,
- multiple testers execute the same test,
- results must be auditable,
- subtle differences in execution matter.
Detailed Steps are about control, not convenience.
Separating execution from verification
Each Detailed Step should:
- describe one action,
- have one corresponding Expected Result.
This separation:
- improves clarity,
- simplifies defect reporting,
- avoids ambiguous results.
Mixing actions and verification in a single step is a common source of confusion.
Internal vs Client-Facing test cases
Step granularity often depends on the audience.
Internal test cases
- executed by QA or the delivery team,
- assume shared context and system knowledge,
- can rely more on High-Level Steps,
- often use fewer Detailed Steps.
Client-Facing (UAT) test cases
- executed by business users,
- require explicit instructions,
- must avoid assumptions,
- rely heavily on Detailed Steps.
Choosing an inappropriate level of granularity for the audience leads to frustration and poor results.
A common anti-pattern: skipping High-Level Steps
Some teams jump directly into Detailed Steps.
This usually results in:
- long, unreadable test cases,
- duplicated execution logic,
- missing checkpoints,
- poor review quality.
High-level steps serve as a structural backbone.
Detailed Steps should attach to that backbone, not replace it.
Practical guideline
A healthy Salesforce test case usually follows this pattern:
- Clear Preconditions
- A small set of High-Level Steps
- Detailed Steps only where precision is required
If Detailed Steps dominate the test case:
- maintenance cost increases,
- test intent becomes harder to see,
- coverage quality decreases.
Key takeaway
- High-Level Steps define what happens.
- Detailed Steps define how it happens.
- High-Level Steps stabilise test cases.
- Detailed Steps control execution when precision is required.
Effective Salesforce test cases use both — deliberately and consciously.