Identifying Gaps & Ambiguities

02.02 — Identifying Gaps & Ambiguities in Requirements

Why Most Salesforce Requirements Are Not Testable (Yet)

If you stay long enough in Salesforce projects, you will notice one truth:

Most requirements arrive incomplete — and some arrive wrong.

This is not a failure of Business Analysts or Product Owners.
It is a natural consequence of how Salesforce projects operate:

• Requirements are written in business language, not system language.
• Salesforce logic is interconnected, so missing one detail can break five others.
• Stakeholders think in outcomes, not conditions.
• Many “requirements” are actually assumptions.
• Some logic is already in the system — but nobody remembers it.

That is why the most powerful skill of a Salesforce QA Consultant is not “testing”.

It is detecting gaps and ambiguities before testing begins.

This lesson teaches you how.

---

Why Gaps Occur in Salesforce Projects

Gaps do not appear because people are careless.
They appear because Salesforce itself is complex:

• Data model influences automation
• Security influences behaviour
• Flows interact with validation rules
• UI visibility hides or reveals logic
• Apex can override declarative processes
• OWD & sharing rules change everything
• Record types alter allowed field values

One missing detail can crash an entire business flow.

Your job is to catch these issues early.

---

The Three Types of Gaps

Every requirement gap in Salesforce belongs to one of these groups:

---

1. Missing Information
Something essential to system behaviour is not specified.

Example:
“Create Contract automatically when Opportunity → Closed Won.”

Missing:

• Who is allowed to create a Contract?
• Should Contract Owner = Opportunity Owner?
• What fields are pre-filled?
• What if required fields are missing?
• Does it apply to all Record Types?
• Should automation run on bulk updates?

If you don’t ask → you will miss hidden test conditions.

---

2. Ambiguous Information
The requirement is written in a way that can be interpreted in multiple ways.

Example:
“When Case is urgent, escalate it.”

Ambiguities:

• What makes a Case urgent?
• Who escalates?
• Does escalation always reassign ownership?
• Do we send notifications?
• What happens if Case is already escalated?

Ambiguity = high defect probability.

---

3. Incorrect Assumptions
The stakeholder believes something works a certain way — but Salesforce does not operate like that.

Example:
“Let’s create a validation rule to prevent updates on Closed Cases.”

Problem:

• Auto-close logic may update Case after closure.
• Integrations often update Closed Cases.
• Workflows or flows may rely on post-close edits.

The requirement contradicts Salesforce architecture.

As a tester, you must catch this before development begins.

---

The Gap Detection Framework

Use this 6-step framework on every requirement.
You will immediately see what’s missing.

---

Step 1 — Actor Analysis
Is it clear who performs the action?

Check for:

• profile
• permission sets
• role
• record visibility

Red flag examples:

• “User can approve request” → which user?
• “Manager updates field” → what defines a Manager?

If the actor is not defined → gap detected.

---

Step 2 — Trigger Analysis
What exactly starts the logic?

UI edit?
Flow?
Before/after update?
List view edit?
API call?
Integration event?

Most requirements only describe the symptom, not the entry point.
Without the trigger, the requirement is incomplete.

---

Step 3 — Data Model Analysis
Does the requirement specify:

• which objects are involved?
• which fields must exist?
• which fields are required?
• which record types apply?
• any picklist logic?

If not → you cannot write test conditions.

---

Step 4 — Security Analysis
Most business people forget security exists.
Developers forget it too.

You must ask:

• Can the actor perform the action with current CRUD/FLS?
• Can automation perform the action?
• Are sharing rules aligned with expected behaviour?

Missing security assumptions = guaranteed UAT failure.

---

Step 5 — Negative & Exception Path Analysis
Almost no requirement mentions:

• what should not happen
• what happens when data is invalid
• what happens when logic is triggered twice
• what should happen in bulk operation

If negative paths aren’t defined → defects are guaranteed.

---

Step 6 — Cross-Logic & Dependency Analysis
This is where senior testers shine.

Ask:

• What existing automation impacts this?
• Could this contradict validation rules?
• Does it align with existing flows?
• Does Apex override part of this behaviour?
• Will this trigger other downstream automations?

Salesforce is a domino system.
A small change can create massive side effects.

---

Example Walkthrough — Live Gap Analysis

Requirement:

“When Case Priority = High, notify the Support Manager.”

Now apply the framework.

---

✔ Actor Analysis
Who triggers the notification?
Support Agent? System? Integration?
Is “Support Manager” a Role? Queue? User name?

---

✔ Trigger Analysis
Does notification fire:

• on create?
• on update?
• only when Priority changes?
• when Priority is set back to High after being Low?

---

✔ Data Model Analysis
Is Priority picklist customized?
Does every Case have a Manager?
Is “High” available for all Record Types?

---

✔ Security Analysis
Can automation user send email alerts?
Can Support Agent edit Priority?
Does Manager have access to the Case?

---

✔ Negative Paths
What if:

• Priority is already High?
• Case is Closed?
• Manager is inactive?
• Email deliverability is off?

---

✔ Dependencies
Does an escalation rule already exist?
Do existing flows send other notifications?
Is there risk of duplicates?

---

Outcome:
A single-sentence requirement produces 15+ gaps.

This is normal.
And this is why analysis is your most critical skill.

---

The Golden Rule of Gap Detection

If you cannot answer every “Who? Where? What? When? Why? How?” question —
the requirement is not testable.

Your role is not just to test.
Your role is to make the requirement testable.

---

How to Communicate Gaps Professionally

The best testers don’t just find gaps — they present them in a calm, structured, solution-ready way.

Example message to Business Analyst:

• 02.02.01 — How to Identify Missing Information

02.02.01 — How to Identify Missing Information

The Fastest Way to Detect Requirement Gaps Before They Become Defects

Missing information is the single most common problem in Salesforce requirements.

Not incorrect logic.
Not low-quality documentation.
Not miscommunication between stakeholders.

Just missing pieces — usually because Salesforce behaviour depends on details business users never think to specify.

Your job as a Salesforce QA Consultant is not to “fill the gaps later.”
Your job is to spot the gaps instantly, while reading the requirement — before the developers start building and before the project timeline takes damage.

This lesson shows you how to do that.

---

Why Information Goes Missing

There are three primary reasons:

1. Business people describe outcomes, not system rules.

They do not think in CRUD, FLS, triggers, flows, or Apex context.

2. Consultants describe the solution, but not all constraints.

They rarely include role visibility, exception logic, or data dependencies.

3. Salesforce automations interact in ways nobody memorises.

Flows, validations, Apex, and sharing rules can all contradict each other.

Even with the best BA, it is impossible to write a complete requirement without missing something.

---

The “Seven Missing Pieces” Model

(What is always missing from Salesforce requirements)

As a rule of thumb, you should expect these seven areas to lack crucial details:

---

1. Missing Actor Definition

Requirements rarely specify:

• which user profile
• which permission set
• which role
• what record access level is needed

Without a clearly defined actor, no test can be designed properly.

Questions to ask:

• Who performs this action?
• Who must not be able to perform this action?

---

2. Missing Trigger Definition

The requirement describes what, but not when.

Example requirement:

"When Priority = High, send email to Manager."

Missing:

• On create?
• On update?
• On mass update?
• On assignment rule?
• On API?
• On automation-driven update?

Triggers define the entire behaviour.
If you do not know when logic starts, you cannot test it.

---

3. Missing Data Model Details

Business users don’t think in:

• required fields
• field types
• record types
• picklist dependencies
• cross-object relationships

If the requirement touches any fields, 80% of the time, you must ask for missing details.

---

4. Missing Security Context

This is a hidden killer of Salesforce projects.

Typical requirement:

"User updates Opportunity Stage."

Missing:

• Does that Profile have Edit access?
• Does FLS hide required fields?
• Can the user see related data?
• Does role hierarchy restrict access?
• Should all users edit Stage or only some?

Security is never fully described in requirements.

---

5. Missing Logic Interaction Rules

Salesforce logic layers interact in this order:

1. Before trigger
2. Validation rules
3. After trigger
4. Assignment rules
5. Auto-response
6. Workflow (legacy)
7. Process Builder
8. Flow
9. Escalation
10. Roll-ups & async logic

Nearly all requirements forget to mention which logic already exists.

---

6. Missing Negative & Exception Paths

Requirements rarely include:

• what should not happen
• how to handle missing data
• what error messages must appear
• what should happen when automation runs twice
• what happens with partial updates

Without negative behaviour defined, half of your test conditions don’t exist yet.

---

7. Missing Dependencies

Every Salesforce object participates in other processes.

Examples:

• Changing Opportunity triggers Case updates.
• Updating Contact may trigger Marketing automations.
• Lead conversion triggers multiple downstream processes.
• Sharing model changes may break flows.

Requirements almost never list dependencies.

---

How to Detect Missing Information in Less Than 30 Seconds

(A Consultative Technique Used by Senior Test Leads)

Here is the fast mental process you can use:

---

Step 1 — Identify what the requirement changes.

Ask:

• Is this about data?
• logic?
• automation?
• UI?

---

Step 2 — Ask “Who?” immediately.

If the actor is not explicitly stated → missing info.

---

Step 3 — Ask “When does it trigger?”

If not stated → missing info.

---

Step 4 — Ask “Which fields/objects?”

If this cannot be answered → missing info.

---

Step 5 — Ask “What is the failure behaviour?”

If not described → missing info.

---

Step 6 — Ask “What else in Salesforce already reacts to this?”

If nobody knows → missing info.

---

Step 7 — Ask “Does user access support this behaviour?”

If unverified → missing info.

You can reliably detect 70–90% of missing information using these seven steps.

---

Real Example — Requirement With Missing Information

Requirement:

“Add validation that prevents closing Opportunity without Quote.”

Missing pieces:

Actor

• Who closes Opportunity?
• Can every profile close it?

Trigger

• On Stage change only?
• On API update?
• During Lead conversion?

Data Model

• What defines a Quote?
• Should Draft Quotes count?

Security

• Does the actor even have access to Quotes?

Negative path

• What if Quote exists but is not approved?
• Should error message appear on Lightning UI and API?

Dependencies

• Flows may auto-close Opportunity
• Integrations may set Stage = Closed Won

This requirement has 8 missing items before test design even begins.

---

What Happens When Missing Information Isn’t Detected?

• Developer builds wrong logic
• Tester writes incomplete test cases
• UAT users report defects that aren’t defects
• Business loses trust in the delivery team
• Sprint velocity collapses
• Project timeline stretches
• Pressure increases
• Quality drops further

Good testers catch missing info early.
Great testers do it instantly.

---

Key Takeaways

• Missing information is the default in Salesforce requirements.
• The “Seven Missing Pieces” model helps you spot gaps instantly.
• If actor, trigger, data model, security, negative path, dependencies, or interactions are unclear → the requirement is not testable.
• Your value as a QA Consultant is highest before development begins.

---

Next lesson
02.02.02 — Conflict Detection (logic, access, timing)
We’ll explore how logic layers contradict each other and how to detect fatal conflicts before they appear in the org.

02.02.02 — Conflict Detection (logic, access, timing)

How Salesforce Creates Hidden Conflicts — and How Testers Detect Them Before They Break the Org

Conflict detection is one of the most advanced skills in Salesforce testing.

It is where mid-level testers fail most often — and where strong QA Consultants become irreplaceable.

Salesforce is a platform filled with layered logic, independent access controls, and execution timing rules that stack and collide in unpredictable ways. Even a perfectly written requirement can become untestable or unbuildable because of conflicts nobody noticed early enough.

This lesson teaches you how to detect these conflicts before development begins.

---

Why Conflicts Happen in Salesforce

Conflicts emerge because Salesforce is not a single logic engine.
It is a stack of independent systems, each with its own rules:

• Sharing model
• Profile & FLS
• Validation Rules
• Before/After Triggers
• Flows (Record-Triggered, Screen, Scheduled)
• Process Builder (legacy)
• Workflow Rules (legacy)
• Assignment & Auto-Response Rules
• Rollups
• Integrations
• Apex
• UI restrictions
• API behaviour

Each layer works correctly on its own, but combining even two layers often produces contradictory behaviour.

Your job is to identify where and how these contradictions occur.

---

The Three Conflict Categories

There are three major types of conflicts you must detect:

---

1. Logic Conflicts

When two automation processes try to do incompatible things

Logic conflicts happen when:

• two automations update the same field differently
• a Flow contradicts an Apex trigger
• one automation relies on data that another automation changes
• Flows fire recursively
• validation rules block updates triggered by Apex

These are often invisible to analysts and developers because each piece “makes sense” in isolation.

Classic example:
A requirement says “When Stage = Closed Won, set Contract Sent = TRUE.”
But another dependency (missed in analysis) says “Contract Sent cannot be TRUE unless Legal Status = Approved.”

The result → the automation breaks instantly.

---

2. Access Conflicts

When users technically should perform an action… but Salesforce security prevents them

These conflicts come from:

• FLS hiding required fields
• Profiles preventing Edit access
• Record access blocking updates
• Permission Sets missing on some roles
• Flows running “before save” but failing because the user cannot write the field
• Apex running in system mode, but UI actions running in user mode

Access conflicts destroy business processes — often silently.

Real example from projects:
A Flow updated a field that standard users could not edit.
The Flow ran before save in user mode → error.
Nobody noticed until UAT.

---

3. Timing Conflicts

When two or more automations run in the wrong sequence

Timing conflicts appear when:

• Apex runs before Flow, overwriting its work
• Flows run before Validation Rules
• Screen Flows rely on data not yet committed
• Integrations update a record between two internal automations
• Process Builder chains fire out of expectation
• Scheduled jobs modify data that should be “locked”

Timing problems are subtle — and almost always produce flaky, inconsistent behaviour.

Example:
A Flow updates “Total Revenue.”
An Apex trigger recalculates “Total Revenue” again in After Update.
Depending on which system assigns values last, numbers become unstable.

---

The 12 Most Common Conflict Scenarios in Salesforce Projects

These patterns appear in almost every project:

1. Validation Rule blocking automation updates
2. Inconsistent field-level security between roles
3. Before-save Flow contradicting Apex before trigger
4. After-save Flow re-triggering automation loops
5. API inserting records missing required fields
6. Integrations overwriting user-entered values
7. Lightning UI enforcing restrictions not present in API
8. Required fields blocked by FLS
9. Profile lacks permission for automated field updates
10. Rollup summaries failing because records are not committed yet
11. Sharing rules hiding related records needed by automation
12. Two Flows updating the same formula-dependent field

If you recognise these patterns, you can predict conflicts before they happen.

---

How Salesforce QA Consultants Detect Conflicts Early

To detect conflicts, you use three structured questions:

---

1. “What else touches the same object or field?”

Scan:

• Flows
• Apex
• Validation Rules
• Triggers
• Integrations
• Rollup summaries
• UI components

If the requirement changes a field touched by any other logic → conflict risk.

---

2. “Who executes this action?”

Because:

• Admins bypass rules
• Standard users don’t
• Flows may run in user mode
• Apex often runs in system mode

Knowing the actor means knowing whether logic will break.

---

3. “When does each part run?”

Map the execution order:

1. Before Triggers
2. Validation Rules
3. After Triggers
4. Workflow/Process Builder
5. Flows (various categories)
6. Rollups
7. Async logic

If two steps rely on the same field → a conflict will appear.

---

Example: Full Conflict Analysis

Requirement:

“When Case Priority = High, assign it to VIP Queue and send notification.”

Hidden conflicts:

Logic conflicts:

• Case Assignment Rules may override the queue
• After-update Flow may assign to a different queue
• Email Alerts from Process Builder may duplicate notifications

Access conflicts:

• User may not have access to VIP Queue
• FLS may hide required routing fields

Timing conflicts:

• Assignment rules fire before Flow
• Flow updates queue after rules → inconsistent assignment

This requirement has six conflict risks before testing begins.

---

Deliverables for QA Consultants

When you detect conflicts, you must:

• Document contradictions
• Provide clear explanation
• Suggest safe alternatives
• Recommend combining or deprecating legacy logic
• Estimate additional risk

This is one of the areas where your value as a QA skyrockets.

---

Key Takeaways

• Salesforce conflicts arise from logic, access, and timing layers.
• You must check what logic touches the same fields, who executes the actions, and when automations run.
• Many business requirements are technically correct but practically impossible without redesign.
• Detecting conflicts early saves hours of debugging and weeks of sprint delays.

---

Next lesson
02.02.03 — Hidden Conditions Caused by Salesforce Architecture

• 02.02.02 — Conflict Detection (logic, access, timing)

02.02.03 — Hidden Conditions Caused by Salesforce Architecture

Why Salesforce Creates “Invisible” Test Conditions — and Why Only Skilled Testers See Them

Most testers focus only on what the requirement says.
Senior Salesforce QA Consultants focus on what the requirement implies.

This difference is what separates average testing from expert-level Salesforce analysis.

Because Salesforce is a platform, not a custom-built system, every change interacts with dozens of invisible mechanisms: sharing, caching, automation order, governor limits, object metadata, field-level security, lookup filters, implicit rollups, and more.

These architectural constraints create hidden test conditions—conditions that no one asked for, no one documented, and often no one even noticed.

Identifying them is your job.

---

Why Hidden Conditions Exist in Salesforce

Hidden conditions emerge because Salesforce:

• executes logic in a strict but non-obvious order,
• enforces security rules in multiple independent layers,
• treats automation differently depending on the execution context,
• does not allow modification of platform-level processing,
• imposes governor limits that indirectly influence system behaviour,
• handles UI and API operations under different constraints.

This means that requirements don’t exist in isolation — they always interact with dozens of platform features.

You are not testing a feature.
You are testing a feature inside Salesforce.

---

The 6 Categories of Hidden Conditions Every Tester Must Recognize

These are the architectural “traps” baked into Salesforce.

1. Hidden Conditions from Object Model Rules

These come from metadata:

• Required fields that UI hides but API demands
• Lookup filters that silently reject invalid data
• Auto-created child records
• Default values that override automation
• Implicit rollups that recalculate only under strict rules
• Duplicate rules unexpectedly blocking inserts

Example:
A requirement says: “When a Lead is converted, associate it with an existing Account.”
Hidden condition: Conversion requires an Account Name unless Account lookup is prefilled.
If the field is restricted via FLS → failure.

---

2. Hidden Conditions from Security Architecture

Three separate systems affect access:

• Profile & Permission Set CRUD
• Field-Level Security
• Sharing & OWD rules

Even if business logic “should work,” Salesforce may block it.

Example:
An automation updates a field — but the user cannot edit this field → Flow fails.
Developers test as Admin → they don’t notice.

---

3. Hidden Conditions from Automation Layering

Salesforce allows multiple overlapping automation types:

• Record-triggered Flows
• Before-save Flows
• After-save Flows
• Apex Triggers
• Process Builder
• Workflow Rules
• Assignment and Auto-Response Rules

Each runs at a different time, with different permissions.

Examples:

• Before-save Flow updates a field → Apex before trigger overwrites it.
• Apex trigger recalculates a value → Flow recalculates it again → unpredictable results.
• Two Flows run at the same time → recursive updates → governor limit error.

---

4. Hidden Conditions from Data Context

Some logic behaves differently depending on how many related records exist, or what shape the data has.

Common cases:

• Rollup summaries behave differently on insert vs update vs delete
• Parent automations fire multiple times for batch operations
• Lookup relationships behave differently depending on record visibility
• Flows run per-record even in bulk operations

Example:
A requirement works perfectly with 5 records — but breaks when there are 500 records because the Flow hits limits.

---

5. Hidden Conditions from Execution Context

Salesforce runs logic in different “modes”:

• User mode
• System mode
• Mixed mode
• “Without sharing” Apex
• API context
• UI context

Each context has its own privileges and restrictions.

Example:
UI forces required fields.
API does not enforce them unless they are system-required.

Meaning: data coming from integration can bypass UI rules → hidden condition emerges.

---

6. Hidden Conditions from Salesforce Limits (Governor Limits)

Governor limits silently create scenario-dependent behaviour:

• CPU time
• DML limits
• SOQL limits
• Heap size
• Flow element execution limits
• Email limits
• Scheduled job concurrency

Example:
A Flow with 10 loops works for one record.
Fails instantly when 50 records are created in bulk.

Tests must include:

• “Normal load”
• “Max load”
• “Abnormal load”

---

How to Identify Hidden Conditions (Method for QA Consultants)

When analyzing any requirement, ask:

---

1. “What does Salesforce require for this feature to function?”

Even if business logic does not mention it.

Examples:

• Converting a Lead requires certain fields.
• Creating Opportunity Products requires Pricebook Entry access.
• Subflows require all referenced fields to be accessible.

---

2. “What parts of Salesforce might influence or contradict this change?”

Scan for:

• Flows
• Triggers
• Sharing rules
• Lookup filters
• Validation rules
• Duplication rules
• Permission sets
• Sync integrations

This single step identifies ~60% of hidden conditions.

---

3. “How will data behave in different volumes?”

Salesforce behaves differently at scale.

Always consider:

• 1 record
• 10 records
• 500 records

If the logic depends on iteration or recursion → hidden condition.

---

4. “Does this requirement contradict anything that already exists?”

Examples:

• New validation rule contradicts existing automation
• Flow conditions contradict object OWD
• Required field contradicts UI page layout

Mapping contradictions is your job — analysts rarely know enough about architecture to detect them.

---

A Real Example From a Salesforce Project

Requirement:

“When Contract Status = Signed, set Activation Date = today.”

Hidden conditions:

Architecture-level

• Activation Date may be read-only in some regions
• A before-trigger recalculates Activation Date from external system
• A Flow updates Contract Status dynamically → recursion risk

Security-level

• Standard users cannot edit Activation Date
• Profile has FLS read-only on the field
• Integration updates bypass UI-level required fields

Data-level

• Batch update may fire logic differently than single update
• Contracts linked to multiple Assets require different updates

Result:
11 hidden conditions from a simple two-line requirement.

---

Why This Skill Makes You a High-Value QA Consultant

Identifying hidden conditions:

• Prevents late-stage failures
• Avoids contradictory requirements
• Saves time for developers
• Builds trust with business teams
• Reduces UAT defects dramatically
• Positions you as an architect-level thinker

This is the difference between “tester” and “Salesforce QA Consultant.”

---

Key Takeaways

• Hidden conditions stem from architecture, not from business requirements.
• Most requirements miss 5–20 conditions that must be analyzed.
• Salesforce’s multi-layer security, logic and timing architecture dramatically increases complexity.
• Your expertise lies in detecting what no one wrote down.
• This skill becomes essential for SRA (Salesforce Risk Assessment) and test estimation later in the course.

---

Next lesson
02.02.04 — Questions Testers Must Ask (to PM, BA, Dev, PO)

• 02.02.03 — Hidden Conditions Caused by Salesforce Architecture
• 02.02.04 — Questions Testers Must Ask (to PM, BA, Dev, PO)

02.02.04 — Questions Testers Must Ask

(to PM, BA, Dev, PO)

The Salesforce QA Consultant’s Essential Question Framework

Most testers wait for clarity.
Senior testers create clarity.

In Salesforce projects, requirements are rarely complete the first time you see them.
Often they are not even requirements — they are ideas, assumptions, or fragments of business logic captured in a meeting.

Your job is not to guess.
Your job is to ask better questions than anyone else in the room.

This lesson gives you a structured set of questions that uncover hidden logic, reveal risks, expose contradictions, and prevent entire classes of defects — before a single test case exists.

These questions are grouped by the person you ask:
- PM (Project Manager)
- BA (Business Analyst)
- Dev / Solution Architect
- PO / Client Representative

---

Why Questions Are Your Most Powerful Tool

A tester who does not ask questions is not performing analysis.
They are merely checking boxes.

Good questions lead to:

• complete requirements
• clarified expectations
• removal of contradictions
• fewer defects in UAT
• faster development
• more predictable releases
• stronger trust in QA

In Salesforce, where hidden architecture behaviours often contradict business expectations, questions are essential.

---

The Tester’s Golden Rule

If something is unclear, incomplete, contradictory, or simply “feels wrong”, it is wrong — ask.

---

1. Questions to Ask the Business Analyst (BA)

Purpose: Clarify business logic, assumptions, and the expected real-world behaviour.

These questions dig into what the business actually wants, not what ended up written.

Understanding the goal

• What problem is this requirement solving?
• What is the intended business outcome?
• Who benefits from this change?

Understanding the actors

• Which user groups must perform this action?
• What permissions or restrictions do those users have?
• Are there any exceptional users with different behaviour?

Understanding the workflow

• Where in the process does this change happen?
• Which steps come before and after?
• What triggers the action? (manual → button, automatic → condition)

Understanding the data

• Which fields are mandatory for this process?
• Which fields are calculated, defaulted, or prefilled?
• Are any external systems pushing or pulling data?

Understanding the rules

• Are there decision points, branches, exceptions?
• What should NEVER happen?
• Are there limits on how many records/users this process supports?

---

2. Questions to Ask the Product Owner (PO)

Purpose: Clarify priority, edge cases, acceptance criteria, and what “success” means.

POs think business-first, not system-first.
Your job is to align technical behaviour with business expectations.

Acceptance & priority

• What is the minimum acceptable behaviour for go-live?
• What is “nice to have” but not critical?
• Are there scenarios we can safely ignore?

Exceptions

• What should happen if the user does something unexpected?
• Should we block the action, warn the user, or allow it?
• What is the worst-case scenario we must prevent?

Relative importance

• Is accuracy more important than performance?
• Is user experience more important than strict data validation?
• Should system safety override speed?

Success definition

• How will you evaluate whether this requirement is “done”?
• What will business users test in UAT?

These answers define what will eventually become your acceptance criteria.

---

3. Questions to Ask the Developer / Solution Architect

Purpose: Clarify how the system will behave under the hood.

These questions expose hidden conditions, integration points, governor limit risks, and automation conflicts.

Technical implementation

• Will this be implemented using Flow, Apex, or configuration?
• Are there existing automations that might interact with this one?
• Will before-save or after-save logic be used?

Data considerations

• Are there bulk operations to consider (imports, integrations)?
• Should the logic support batch updates?
• Does the implementation risk hitting governor limits?

Security considerations

• Does the automation run in user mode or system mode?
• Will record visibility affect the behaviour?
• Are there fields the user cannot read or edit?

Edge cases

• What happens if multiple users perform this action at the same time?
• What happens if required data is missing?
• What happens if the automation fails?

Dependencies

• Does this logic depend on data created by another system?
• Does this logic create data used by another system?
• Does any part of the implementation depend on timing or order of execution?

Architect-level testers ask these questions before development, not after defects appear.

---

4. Questions to Ask the Project Manager (PM)

Purpose: Clarify deadlines, constraints, risks, and expected test scope.

These questions prevent you from being blamed for unrealistic expectations.

Scope

• Which parts are in scope and out of scope for this sprint?
• Are we testing only functionality, or also performance/UX/data impact?
• Are we expected to support UAT for this requirement?

Timeline

• When will development be ready for testing?
• When does UAT start?
• How much time is allocated for defect fixing?

Risks

• What are the known risks around this requirement?
• Are there other features being developed in parallel that may interfere?
• Is this part of a larger initiative or critical path?

Expectations

• Should tests be light and exploratory, or comprehensive and documented?
• Will screenshots or step-by-step documentation be required?

These questions directly influence your testing level & test planning.

---

5. Universal Questions (Ask Everyone)

These uncover the deepest hidden conditions.

• What happens if the user does NOT follow the “happy path”?
• What happens if this process is repeated multiple times?
• What happens if two processes run simultaneously?
• Are there any other features depending on this behaviour?
• Are there any limits, thresholds, or quotas we need to consider?
• Does this logic behave differently in UI vs API?
• Does integration override, supplement, or conflict with this logic?

If any stakeholder says:

“We didn’t think about that.”

You just prevented a future defect.

---

Why Testers Must Ask These Questions

(and why nobody else will)

• PM rarely understands full technical consequences
• BA rarely knows Salesforce architecture
• Dev rarely sees business context
• PO rarely sees technical risks

But you, the tester, sit exactly in the middle.

Your questions create the bridge between what is wanted, what is possible, and what must be tested.

---

Key Takeaways

• Questions are part of analysis — not a “nice to have”.
• You must ask different groups different questions.
• Your job is to anticipate what they don’t know they need.
• Every unanswered question becomes a defect later.
• The better your questions, the fewer defects reach UAT.

---

Next Lesson
02.02.05 — Case Study: One Requirement → Twenty Hidden Conditions

• 02.02.05 — Case Study: One Requirement → Twenty Hidden Conditions

02.02.05 — Case Study: One Requirement → Twenty Hidden Conditions

Turning a Simple Requirement into a Complete Analytical Breakdown

In Salesforce projects, requirements often arrive looking simple, harmless, almost too easy.

But beneath that simplicity lies the full complexity of Salesforce architecture.

This lesson demonstrates—step by step—how an experienced Salesforce QA Consultant transforms one short requirement into twenty or more test conditions, revealing gaps, conflicts, hidden behaviours, and assumptions no one else identified.

This is the practical application of everything learned in 02.02.

---

The Requirement (Business Version)

“When Opportunity Stage is changed to Closed Won, automatically create a Contract and assign it to the Opportunity Owner.”

At first glance, it looks straightforward:

• Trigger: Stage moves to Closed Won
• Action: Create Contract
• Owner: Opportunity Owner

Feels like 3 test conditions.
In reality? 20+ conditions, spread across five architecture layers.

Let’s walk through the breakdown.

---

Step 1 — Identify Missing Information

Before analyzing anything else, check the requirement for gaps.

Missing:

• Which users are allowed to close Opportunities?
• Does this apply to all Record Types?
• Are there required fields on Contract?
• What happens if Contract already exists?
• What happens if Opportunity is bulk-updated (API/import)?
• Should creation happen only when Stage changes, or also when a Closed Won record is edited?
• What if the Opportunity Owner is inactive?
• Should email notifications be sent?
• Should Contract start/end dates be prefilled?
• Should Contract inherit fields from Opportunity?

Missing info → added questions for BA and PO.

---

Step 2 — Categorize the Requirement

Categories identified:

• Data Model → Opportunity, Contract, fields, record types
• Security → CRUD, FLS, sharing
• Logic → Flow or Apex
• UI → Stage path, visibility
• Timing → Trigger context

Each category generates several hidden conditions.

---

Step 3 — Extract Visible Test Conditions

From requirement text:

1. VC01 — When Opportunity Stage changes to Closed Won → automation must run
2. VC02 — Automation must create a Contract
3. VC03 — Contract Owner = Opportunity Owner

Visible conditions: 3

Now the real work begins.

---

Step 4 — Add Hidden Conditions (from Architecture)

Data Model Conditions

1. DM01 — Opportunity must have required fields populated before Contract creation
2. DM02 — Contract object must allow creation without mandatory fields failing
3. DM03 — Contract Start/End Dates must be defined or defaulted
4. DM04 — Contract Record Type must be determined (if applicable)
5. DM05 — Check if multi-currency impacts Contract values

---

Security Conditions

1. SEC01 — User closing Opportunity must have Edit access to Opportunity
2. SEC02 — Automation user must have Create access to Contract
3. SEC03 — Opportunity Owner must be assignable as Contract Owner
4. SEC04 — Field-level security must allow Contract fields to be populated
5. SEC05 — Role hierarchy must allow the user to view the Contract after creation

---

Logic Conditions (Flow / Apex)

1. LOG01 — Logic must run only when Stage changes to Closed Won (not on update where value stays)
2. LOG02 — Logic must not create duplicate Contracts if Opportunity is updated multiple times
3. LOG03 — Logic must handle bulk updates (mass edit, Data Loader)
4. LOG04 — Logic must not run during imports that bypass UI-required fields
5. LOG05 — Validation rules must not block updates performed by automation

---

Timing Conditions

1. TIM01 — Stage update must occur before automation runs
2. TIM02 — Existing Flows or triggers updating the same fields must not override or duplicate logic
3. TIM03 — Automation must commit data before any downstream system reads Contract

---

UI Conditions

1. UI01 — Contract must appear in Opportunity related list
2. UI02 — Contract fields must display correct default values
3. UI03 — Stage Path must correctly reflect updated stage

---

Step 5 — Identify Conflict Risks

Conflicts likely to occur:

1. Validation rule prevents Contract creation
2. Another Flow already manages Contract logic
3. Apex trigger overwrites Contract Owner
4. API updates bypass logic triggering
5. Duplicate Contracts created by batch updates
6. Contract creation fails due to missing required fields

Each conflict requires investigation or clarification → becomes part of analysis.

---

Step 6 — Final Test Condition Set (20+ Conditions)

You now have a structured, categorized list:

Visible

VC01, VC02, VC03

Data Model

DM01, DM02, DM03, DM04, DM05

Security

SEC01, SEC02, SEC03, SEC04, SEC05

Logic

LOG01, LOG02, LOG03, LOG04, LOG05

Timing

TIM01, TIM02, TIM03

UI

UI01, UI02, UI03

Total: 23 conditions, and this is still a conservative number.

A real project would likely produce 25–30.

---

What This Case Study Proves

A simple two-line requirement hides:

• implicit assumptions
• architectural dependencies
• data prerequisites
• security constraints
• automation conflicts
• alternative execution paths
• bulk behaviour
• UI behaviour
• failure conditions
• upstream and downstream integrations

Business sees a sentence.
You see a system.

This transformation — from requirement text to structured architecture-aware analysis — is what makes you a Salesforce QA Consultant, not just a tester.

---

Key Takeaways

• Every requirement hides multiple layers of behaviour
• The number of real test conditions is often 5–10x the visible ones
• Salesforce QA requires architectural thinking
• Detecting hidden conditions early prevents defects and redesign
• This analysis feeds directly into Test Objectives, SRA, and Quadrants

---

Next Module
02.03 — Test Objectives Creation
Where you will learn how to turn your test conditions into structured, high-level Test Objectives used for planning, estimation, coverage, and communication with business.