Test Analysis 101: The Six Questions That Change Everything
Most junior testers write test cases by reading requirements.
Most senior testers write test cases by analysing requirements.
The difference?
Analysis reveals what the requirement doesn’t say.
Here are the six questions that every professional Salesforce tester must ask — every single time.
1. Who?
Not a person.
A role, a profile, a permission set.
Never write test cases with specific usernames.
Names change.
Assignments change.
Projects change.
Permissions don’t.
Ask:
- Who is the Actor?
- What is their access?
- Should this user see or edit the fields involved?
Why It Matters:
Most Salesforce failures are permission-related, not logic-related.
2. Where?
Every process starts somewhere.
Ask:
- On which object does the logic begin?
- Which screen or action triggers the change?
- Is it in the middle of a multi-step process?
Why It Matters:
If you test the wrong entry point,
you will never reproduce the real behaviour.
3. How?
“How does the logic fire?”
Ask:
- Is the change triggered on create?
- On update?
- On a specific field change?
- On a button click?
- In a Flow (before/after)?
- In Apex (with/without sharing)?
Why It Matters:
Most bugs hide in incorrect trigger timing.
4. Why?
The most underrated question.
Ask:
- What is the business value?
- Why was this requirement created?
- What decision or workflow does it support?
Why It Matters:
Understanding the “Why” reveals missing test conditions
that are never written in Jira.
5. What?
This question addresses delivery method.
Ask:
- Is this done with configuration or code?
- Does it use automation? Which type?
- Are multiple processes touching the same object?
Why It Matters:
Declarative logic creates invisible dependencies.
Apex creates performance and limit-related dependencies.
Both are dangerous in different ways.
6. When?
Timing is everything.
Ask:
- When in the business process does this happen?
- Before or after record save?
- Before or after another automation?
Why It Matters:
Salesforce loves to execute automation in a surprising order. Which means, not in all cases, Salesforce Team create logic in the correct order.
Understanding “When” eliminates those surprises.
Practical Example
Requirement:
“When Case Priority = High, notify the Support Manager.”
Ask the six questions:
Who?
Support Agents? Sales? Admin?
Only some users should trigger the rule.
Where?
Case record? Quick Action? Closed status?
How?
Flow? Email alert? Apex? Before-save update?
Why?
Is this compliance? SLA requirement? Escalation?
What?
Does the change require new FLS? New field? Additional logic?
When?
On creation? On update? Only when increasing priority?
Suddenly, the requirement becomes clear.
Final Thoughts
Using the six questions turns you from someone who clicks test cases
into someone who designs testing.
And testers who design tests
shape projects.
If you want, I can turn this into a printable checklist for your QA toolkit.