When you join your first Salesforce project, you usually expect requirements to behave the way they are described in certifications, books, or ISTQB materials: clear, structured statements explaining exactly what the system should do.

But Salesforce projects don’t work like that.

The sooner you accept it, the better tester you become.

In traditional software testing, requirements often describe functionality that developers will build from scratch. You are verifying logic that your team creates. In Salesforce, however, you are verifying solutions built on top of a platform, with a pre-existing architecture, limitations, automation layers, and a complex security model. Requirements do not — and cannot — fully describe how all of this should behave.

This leads us to the fundamental truth of testing in this ecosystem:

A requirement is never the thing you test.
A requirement is only the starting point of analysis.

If you treat it as a complete description of expected behaviour, you will fail every time.

---

Requirements Express Business Intentions, Not System Behaviour

A requirement in Salesforce should never be interpreted as a technical specification. It is simply a business intention — a statement describing what the organisation wants to achieve.

For example, take this common requirement:

“When a Case is closed, its Record Type must update based on the case category.”

This is not a description of logic.

This does not tell you how the change is implemented.

It certainly does not tell you what the edge cases are.

A Salesforce requirement tells you the desired outcome, not the configuration or technical process behind it. It’s a declaration of value and intent.

What you see in the documentation is just one thin layer of the system — the visible part. What matters for valid analysis is everything underneath:

• Data structure changes
• Access restrictions (Profiles, Permission Sets)
• Record-level visibility issues (Sharing Rules)
• Dependencies inside automation (Flow vs. Apex order)
• Interactions with other features
• Platform constraints (Governor Limits)

A requirement describes none of these, but all of them influence how the feature must be tested.

This is why the most important skill of a Salesforce tester is not reading documentation — it is interpreting documentation through the lens of how Salesforce actually works.

---

Most Requirements Are Incomplete by Design

There are three main reasons why requirements in Salesforce projects are almost always incomplete. This is not necessarily a failure of the analyst; it is a feature of the ecosystem.

1. Business users think in terms of process, not system behaviour

They describe what must happen, not how the system needs to be configured. Their world is simple: “I click here, I do this, the system gives me that.” Everything else — permissions, logic, data dependencies — is invisible to them.

2. Consultants implement features using different layers of configuration

Flow, validation rules, object model changes, formulas, Apex, UI settings — each part may affect the behaviour, but none of this is usually reflected in the requirement text. Even the consultant may forget to mention part of the configuration if it feels “obvious” from a Salesforce perspective.

3. Salesforce automatically connects parts of the system the requirement never mentions

A field change can trigger a Flow. A Flow can fire an Apex class. A sharing rule can block the result. A missing FLS checkbox can break the entire process.

None of this is written in the requirement — but all of it affects the tester’s work.

A Salesforce requirement is not incomplete because someone made a mistake.
It is incomplete because it is impossible to describe everything manually without duplicating Salesforce documentation.

Your job as a tester is to fill in these gaps through analysis.

---

A Requirement Describes Scope — Not Detail

A common mistake junior testers make is assuming that the requirement describes the behaviour that must be tested. If something isn’t explicitly written, they assume it must not matter.

In Salesforce, the opposite is true:

If something isn’t written, it might matter even more.

For example:

A requirement says “User should be able to update Opportunity Stage.”

But it does not mention:

• Sales Process restrictions
• Validation rules
• Record-level access
• Stage-dependent automation

All of that must be tested.

Salesforce testers must understand a simple but crucial rule:

Every requirement implies logic that is not documented.

This is why requirement analysis in Salesforce is a multi-layer process — and why this module is significantly more complex than the basics.

---

Requirements Must Always Be Interpreted Through Platform Categories

To understand what a requirement actually means, you must map it automatically to its underlying Salesforce layers:

1. Data Model — What fields, objects, and dependencies are affected?
2. Security — Who is the actor? What access do they need?
3. Declarative Logic — Do Flows or Process Builders trigger?
4. Apex Logic — Is there custom code that influences behaviour?
5. UI — What layouts, components, or visibility filters apply?

Salesforce testers don’t test features. They test how configuration, automation, and access come together to create behaviour. A requirement is simply the window through which you view the system — not the system itself.

---

Why This Matters: The Admin Fallacy

One of the classic mistakes every tester makes once — and only once — is testing with Admin access.

As long as you test with Admin, every requirement looks correct.

• Flows work.
• Apex works.
• Data saves.
• Validation rules behave.
• Record types change.
• Sharing rules magically disappear.

Because Salesforce Admin is not a user — it is an omnipotent observer.

Real users:

• Cannot see every field.
• Cannot edit every object.
• Cannot execute every query.
• Cannot trigger every automation.

Requirements are written with business users in mind — and so the tester must analyse the requirement through the eyes of those users, not the eyes of the Admin.

---

Key Takeaways

• A requirement is not a description of logic — it is a business intention.
• Requirements are incomplete by design in Salesforce.
• The tester must interpret requirements through Salesforce categories (data, security, logic, UI, Apex).
• Requirements describe outcomes, not configuration.
• Missing details are not errors — they are expected.
• Analysis, not documentation, defines what must be tested.
• Testing with Admin access makes every requirement appear correct — and this is the danger.

02.01.02 — Why Requirements Are Often Wrong or Incomplete

One of the biggest surprises for people entering Salesforce projects—especially those coming from traditional software testing—is discovering how often requirements are incomplete, ambiguous, or simply wrong.

Not because someone failed to do their job.

But because Salesforce projects make complete requirements practically impossible.

If you expect perfectly described behaviour, step-by-step acceptance criteria, and a full system blueprint embedded in Jira tickets, you are setting yourself up for constant frustration.

Salesforce doesn’t work that way.

Salesforce cannot work that way.

And the earlier a tester understands this, the faster they grow into a true Salesforce QA Consultant.

---

Requirements Fail Because They Focus on Business Outcome, Not System Behaviour

In Salesforce, a requirement is usually a business request, not a technical description.

For example, look at this seemingly innocent requirement:

“Add validation so that Case cannot be closed without Resolution.”

Looks simple.

Clear.

Unambiguous.

But this small sentence hides multiple layers of platform-specific behaviour:

• Which users can close the Case?
• Do all Profiles see the Resolution field?
• Does the validation fire in API calls?
• Does automation update Case status in the background?
• Is there an integration that changes the status without UI interaction?
• Do flows run before or after validation?
• Does a Record-Triggered Flow retry or suppress the validation?

None of this is written in the requirement.

Yet all of it is crucial.

Salesforce requirements fail not because business analysts are careless, but because Salesforce behaviour depends on far more components than the requirement describes.

---

Business People Describe Problems, Not Systems

A business user will always describe:

• what they want to achieve,
• what is currently wrong,
• what should be different.

They will never describe:

• access levels,
• field visibility,
• trigger order,
• flow entry conditions,
• sharing rules,
• record lifecycle variations.

Why?

Because they don’t see the system the way testers do.

Their perspective is purely operational:

“I can’t close the Case, so fix it.”

You, as a tester, must interpret that sentence through all the Salesforce layers that business users will never mention.

---

Consultants Describe the Solution—But Not All of It

Even excellent consultants do not list every element included in a configuration change.

Not because they don’t want to, but because the platform is deeply interconnected.

A requirement saying:

“Add a mechanism that recalculates Discount.”

might require changes in:

1. Data Model (fields, formulas, rollups)
2. Declarative logic (Flows, decision nodes, assignments)
3. Apex (custom logic for validation or integration)
4. UI (visibility filters, dynamic forms)
5. Security (FLS for the calculated fields)
6. Record-level access (who can change product prices)

The requirement will mention none of these.

The Jira ticket will mention none of these.

The acceptance criteria will mention none of these.

But everything influences the final behaviour.

This means:

In Salesforce, no requirement describes the real implementation.

It only describes the first layer of it.

---

The Illusion of Completeness in Agile Projects

Agile is fantastic for flexibility.

It is terrible for completeness.

User Stories are designed to be intentionally short and open-ended:

“As a user, I want X so that Y.”

Acceptance criteria usually describe the happy path, not:

• negative behaviour,
• actor variations,
• special cases,
• data dependencies,
• automation interactions,
• external system impacts.

A tester who expects completeness will miss half the behaviour.

A tester who expects ambiguity will detect it early and ask the right questions.

---

Salesforce Amplifies Every Missing Detail

Salesforce is not a monolithic application.

It is an ecosystem with:

• shared automation,
• inherited security rules,
• dynamic UI filters,
• asynchronous processes,
• deeply connected objects,
• trigger order that cannot be fully controlled.

This means that small requirement gaps turn into massive testing implications.

A missing detail like:

• “User does/does not have access to Field X”
• “Flow runs in system/user context”
• “Record Type changes behind the scenes”

can completely change how the feature works.

In custom software, missing details limit your understanding.

In Salesforce, missing details change the behaviour.

This is why you cannot take requirements literally.

---

Incomplete Requirements Are Not a Mistake—They Are Normal

A tester who expects perfect documentation will always feel overwhelmed.

A tester who accepts ambiguity as a normal part of Salesforce work becomes far more effective.

The truth is:

• requirements are incomplete by nature,
• documentation never represents the entire system,
• automation behaves differently depending on context,
• user access changes outcomes in ways not described anywhere.

Your job is not to “follow requirements”.

Your job is to analyse requirements and reveal everything that is missing.

---

Why This Matters for Test Analysis

If you assume the requirements are complete, you will:

• miss hidden conditions,
• fail to test negative scenarios,
• ignore security layers,
• misinterpret business process flow,
• assign test conditions to wrong quadrants,
• underestimate actual risk.

If you assume the requirements are incomplete, you will:

• ask the right questions,
• uncover hidden dependencies,
• map logic correctly,
• produce accurate Test Objectives,
• design stronger tests,
• detect weak points in implementation before UAT begins.

The difference is not in skills.

The difference is in mindset.

---

Key Takeaways

• Requirements in Salesforce describe intentions, not system behaviour.
• They appear complete but hide multiple invisible layers.
• Business users describe outcomes, not logic.
• Consultants describe configuration, but never all of it.
• Agile makes requirements concise—but incomplete.
• Salesforce multiplies the impact of missing details.
• Effective testers assume ambiguity and resolve it through analysis.
• Test Analysis is the process of uncovering everything the requirement does not say.

02.01.03 — The Five-Read Method

A Practical Framework for Deep Requirement Analysis in Salesforce Projects

Most testers read a requirement once and jump straight into writing test cases.

In Salesforce, that approach guarantees missed conditions, wrong assumptions, and endless rework.

Salesforce projects require a different analytical mindset: one where reading is not a single action, but a structured, multi-layer process designed to reveal what the requirement does not say.

The Five-Read Method is the backbone of effective Salesforce test analysis.

It transforms unclear, incomplete requirements into a fully-mapped, testable structure.

Let’s walk through how it works.

---

Why Do We Need Multiple Reads?

Salesforce is not custom software.

A small requirement may impact:

• data model
• security settings
• flows
• Apex
• UI behaviour
• integrations
• record access
• automation order

None of this is explicitly described in Jira tickets.

A single read captures the business outcome.

Multiple reads reveal the hidden layers.

The Five-Read Method is deliberately repetitive: each pass exposes a new dimension of information.

---

Read 1 — The Surface Read: What Does the Business Want?

This read is intentionally simple.

Your only goal is to understand:

• What is being changed?
• Who requested it?
• What business value does it provide?
• What is the expected outcome?

You are not thinking about Salesforce yet.

You are not thinking about negative scenarios.

You are not thinking about data or edge cases.

This read gives you context, not technical insight.

Signals to capture:

• Tone: Is this urgent? critical? a blocker?
• Business intent: What problem is being solved?
• Missing clarity: Does the user even know what they need?

Output of Read 1:

A simple statement:

“I understand the business intent.”

That’s it. Nothing more.

---

Read 2 — Structural Read: Which Salesforce Components Are Touched?

Now you apply your Salesforce knowledge.

You take the requirement and ask:

• Which part of the system could this impact?
• Which declarative tools might be used?
• Is Apex likely?
• Is the user interface expected to change?
• Does the requirement suggest underlying data model updates?
• What existing processes might be affected indirectly?

Signals to capture:

• Are new fields required?
• Are existing validations involved?
• Is there automation related to this object?
• Does the requirement depend on record type?
• Is this user-specific or permission-specific?

Output of Read 2:

A list of possible technical areas, even if not confirmed.

---

Read 3 — Dependency Read: What Can Break? What Can Be Impacted?

This is where most testers fail — they skip this read entirely.

Every Salesforce change has dependencies.

You now ask:

• Will this requirement conflict with existing automation?
• Is there automation firing before or after this action?
• Could record access block or alter the outcome?
• Do we need additional data to fulfil new conditions?
• Does changing behaviour in Object A affect Object B?
• Does the UI expose or hide what we need to test?
• Could integrations override what users do manually?

Concrete examples:

• A Case Status change might trigger a flow, which triggers an Apex callout.
• A new field might require updates in permission sets.
• A validation might break integrations sending partial data.
• A new business rule may block an automated system process.

Output of Read 3:

A map of hidden risk areas.

---

Read 4 — Quadrant Read: How Will This Be Tested?

Now you classify the requirement based on Salesforce Testing Quadrants (adapted):

You ask:

• Which parts go to core checks?
• Which parts go to functional requirement testing?
• Which go to end-to-end business flow?
• Which need exploratory or destructive testing?

For example:

• Field visibility? → Quadrant 1
• Declarative logic? → Quadrant 2
• Cross-object flow behaviour? → Quadrant 3
• Performance or limit testing? → Quadrant 4

Output of Read 4:

A structured set of test categories, each mapped to a quadrant.

This is the step that prevents bloated, chaotic test suites.

---

Read 5 — Test Condition Generation: What Must Be Proven?

Now you combine everything from the previous reads and ask:

“What must I confirm for this requirement to be considered fully tested?”

You generate test conditions — not test cases yet, only conditions:

Examples:

• User with Profile X can perform Action A.
• User with Profile Y cannot perform Action A.
• Field F is required only when Condition C is true.
• Flow executes when Trigger Condition T is met.
• Validation prevents saving incorrect record states.
• Automation updates related object Z.
• Integration does not break when new logic fires.

This is where the requirement becomes fully transparent.

Output of Read 5:

• List of visible test conditions
• List of hidden (implicit) test conditions
• List of negative test conditions
• List of edge-case conditions
• Known risks
• Questions for the BA/Consultant/Tech Lead

This output becomes the foundation for test design in the later module.

---

Putting It All Together

Here’s what actually happens in practice:

1. Read 1: You understand the business value.
2. Read 2: You understand possible technical components.
3. Read 3: You identify hidden dependencies and risks.
4. Read 4: You map how the requirement should be tested.
5. Read 5: You transform everything into actionable test conditions.

A requirement that originally looked like one small feature now becomes:

• a structured analysis,
• a clear testing plan,
• a risk map,
• and a transparent list of conditions.

This is the essence of Salesforce Test Analysis.

---

Key Takeaways

• Requirements in Salesforce are never complete after one read.
• Multiple reads expose layers of behaviour that are otherwise invisible.
• Testers who adopt this method find all important test conditions — not just the obvious ones.
• The method is simple, repeatable, and works for every project type.

02.01.04 — Categorizing Requirements Correctly (Data, Security, Logic, UI, Apex)

The Most Critical Skill in Salesforce Test Analysis

If there is one thing that separates an average tester from a highly effective Salesforce QA Consultant, it is this:

The ability to correctly categorize every requirement before any testing or test-case writing begins.

In Salesforce, categorization is not optional.

It is the only way to understand what you actually need to test.

Most requirements are written from a business perspective — vague, incomplete, and focused on outcomes rather than system behaviour. Categorization acts as the translation layer between business language and Salesforce architecture.

Without it, testers guess.

With it, testers know exactly what needs to be checked.

---

Why Categorization Matters

Salesforce is a connected ecosystem. A change in one area almost always impacts another.

Categorizing requirements ensures you can:

• identify hidden test conditions,
• predict dependencies,
• estimate effort correctly,
• ask the right clarification questions,
• avoid duplicate or unnecessary testing,
• catch problems that developers and BAs may overlook.

It is the first checkpoint of reliable test analysis.

---

The Five Core Categories

Every Salesforce requirement falls into one or more of these categories:

1. Data Model
2. Security Settings
3. Declarative Logic
4. Apex / Programmatic Logic
5. User Interface (UI) Changes

Many testers try to force each requirement into a single category.

That is a mistake.

Most requirements span at least two categories, sometimes all five.

Let’s break them down properly.

---

1. Data Model

The Foundation of Everything in Salesforce

If something changes in Salesforce, there is a high chance the data model is involved.

What belongs here:

• New or modified fields
• Field types & default values
• Field-Level Security (visibility/editability)
• Validation rules
• Relationships between objects
• Record types & picklists
• Field sets (rare but relevant)
• Duplicate rules & matching rules

Questions to ask:

• Does this requirement introduce new data?
• Does it modify how data is stored or validated?
• Are any objects missing fields needed to support the logic?

Rule: If the Data Model is wrong, nothing else in the project will work correctly.

---

2. Security Settings

Who Should (and Should Not) Be Able to Do Something?

Security is always involved, even if not explicitly mentioned in the ticket.

What belongs here:

• CRUD permissions
• FLS (Field Level Security)
• Permission sets & permission set groups
• Profiles
• Roles & role hierarchy (record visibility)
• Organization-Wide Defaults
• Sharing rules
• Manual sharing logic
• Implicit sharing (e.g., parent → child access)

Questions to ask:

• Which user persona should perform the action?
• Are they allowed to create/read/update/delete the relevant records?
• Could record access restrictions block the business flow?

Warning: Misconfigured security is one of the most common sources of defects in Salesforce projects.

---

3. Declarative Logic

“Point-and-Click” Business Automation

This category includes all business logic that Salesforce Admins or Consultants configure without writing Apex.

What belongs here:

• Flows (screen flows, record-triggered flows, scheduled flows)
• Process Builder (legacy but still active in older orgs)
• Workflow rules (very legacy)
• Approval processes
• Assignment rules
• Auto-response rules
• Escalation rules
• Routing logic
• Email alerts
• Formula fields & roll-up summaries

Questions to ask:

• Which automation triggers the logic?
• What are the entry conditions?
• What happens before and after the automation?
• Could automation order cause conflicts?

Context: Declarative logic is often the “invisible middle layer” of Salesforce — easy to miss, yet powerful enough to break entire systems.

---

4. Apex Logic

When Configuration Isn’t Enough

Apex introduces custom behaviour that overrides or extends platform logic.

What belongs here:

• Apex triggers
• Apex classes
• Batch Apex
• Queueable jobs
• Future/async logic
• Callouts
• Custom integrations
• Custom REST/SOAP APIs
• Test classes (developer-side testing)

Questions to ask:

• Is there complex business logic beyond what Flows can handle?
• Does the automation process multiple records?
• Could governor limits be exceeded?
• Does this interact with external systems?
• Is error handling clearly defined?

Risk: Apex logic is high risk. If a requirement touches Apex, you automatically expand the depth of analysis.

---

5. User Interface (UI) Changes

What the User Sees — And What They Don’t

The UI reflects underlying system behaviour. Many requirements seem to be “just layout changes” but actually involve deeper logic.

What belongs here:

• Page layouts
• Lightning pages
• Dynamic forms
• Lightning components (Aura/LWC)
• Visibility filters
• Buttons & quick actions
• Tabs, apps, and navigation items
• List views and filters

Questions to ask:

• Is the UI exposing the correct fields?
• Do visibility rules reflect security correctly?
• Are users shown too much, or too little?
• Is the component behaviour aligned with automation?

Rule: UI testing in Salesforce is more about behavioural correctness than pixel-perfect layouts.

---

How Categorization Actually Works in Practice

Let’s take a simple-looking requirement:

“When Opportunity Stage changes to ‘Closed Won,’ create a Project record automatically and assign it to the Deal Owner.”

This requirement belongs to at least four categories:

• ✔️ Data Model: New relationship between Opportunity → Project. Possibly new fields on Project (Owner, Source Opportunity, etc.).
• ✔️ Security: Can the Opportunity owner create a Project? Does the Project object require specific permissions? Should all users see the new Project?
• ✔️ Declarative Logic: Flow creating the Project. Maybe a record-triggered flow or before-save logic.
• ✔️ Apex Logic (if needed): If the project creation has multiple dependent rules or external systems to notify.
• ✔️ UI Changes: Should the Project appear on the Opportunity page? Should the new Project show pre-filled fields?

This is one requirement. It produces ~30–50 test conditions.

---

Categorization = Better Questions

Once you classify the requirement, you can ask precise, meaningful questions:

• “Does the Opportunity Owner have create access to Project?”
• “What happens if multiple related records exist already?”
• “Is this automation supposed to run only for users in Role X?”
• “Is Project creation synchronous or asynchronous?”
• “Should this automation fire on imports or only UI edits?”

These are the questions that make developers respect you.

They prove you understand Salesforce professionally.

---

Categorization = The Foundation for Test Conditions

In the next topic (02.01.05), we will take the categorized requirement and convert it into a structured set of visible, hidden, and negative test conditions.

But remember:

If you categorize incorrectly, all your test conditions will be wrong.
If you categorize correctly, the test conditions practically write themselves.

---

Key Takeaways

• Every Salesforce requirement must be categorized before testing begins.
• Most requirements touch multiple categories — sometimes all five.
• Categorization exposes hidden risks, missing information, and dependencies.
• It is the fastest way to predict effort, complexity, and potential defects.

This is the analytical foundation of the entire course.

02.01.05 — Extracting Initial Test Conditions (First Visible Layer)

The First Visible Layer of Salesforce Test Analysis

Before you write a single test case, before you decide which Quadrant a scenario belongs to, and before you estimate effort, you must extract test conditions.

Test conditions are the atomic facts that must be validated for a requirement to be considered correctly implemented.

They act as the bridge between:

• business language (what the client thinks they want)
• system behaviour (what Salesforce will actually do)

And this is where Salesforce testers often make their first major mistake:

They jump into writing test cases without identifying test conditions.

Without test conditions, test cases become bloated, repetitive, and unfocused.

With clearly defined test conditions, test-case writing becomes mechanical and fast.

---

What Are Test Conditions?

A test condition is a single statement of behaviour or system expectation that must be true for the requirement to be considered complete.

Examples:

• “User with Profile X can create a Contact.”
• “A validation error appears when Date < Today.”
• “Flow creates a Case automatically when Checkbox = true.”
• “Picklist values differ by Record Type.”

Each of these is a condition, not a test step.

A test case may include multiple test conditions, and one condition may appear in several test cases.

---

The Two Types of Test Conditions

When extracting the first layer, focus on identifying:

1. Visible Test Conditions

These come directly from what is explicitly written in the requirement.

Examples:

• “When Stage = Closed Won → create Contract”
• “Field X becomes required”
• “Only Managers can approve the request”

Visible conditions are usually easy — but they make up only 30–40% of what needs to be tested.

2. Hidden Test Conditions

These do not appear in the requirement text — but always exist because of Salesforce architecture.

Examples:

• CRUD/FLS access needed to perform the described action.
• Record-sharing rules that may block automation.
• Running the logic in bulk (imports, API updates, list views).
• Before/after trigger order.
• Validation rules that might block or override new logic.
• Data dependencies (related records required beforehand).

Hidden conditions are where senior testers outperform junior testers.

Visible = what business thinks the system does.
Hidden = what Salesforce will actually do.

---

How to Extract Test Conditions — The Method

This is the exact method used in consulting projects to extract complete, clean, reliable test conditions.

Step 1 — Categorize the Requirement

Use the five categories from previous lessons:

1. Data Model
2. Security
3. Declarative Logic
4. Apex Logic
5. UI

Each category automatically produces a checklist of condition sources.

Example: If a requirement touches Data Model + Security + Flow → you already know where to look.

Step 2 — Identify the “Actor”

You never use real user names. You define actors by access model:

• “Sales Rep (Profile: Sales User + PS: Opportunity Access)”
• “Back-office user (Role: Operations North)”
• “System automation user”

Each actor brings its own test conditions:

• Can they see the fields?
• Can they modify the records?
• Can they trigger the logic?

Step 3 — Extract All Visible Test Conditions

From the requirement text, rewrite every statement into a condition.

Requirement example:

“When a Lead is converted and Lead Source = ‘Partner Referral’, automatically create a Partner Account and assign it to the Partner Manager queue.”

Visible conditions:

1. Lead conversion works for actor X.
2. Lead Source has value “Partner Referral”.
3. Partner Account is created on conversion.
4. Partner Account is assigned to Partner Manager queue.

This is the easy part.

Step 4 — Derive All Hidden Test Conditions

Now the real work begins. Ask:

• Data Model: Does Lead have required fields for conversion? Is Lead Source picklist accessible? Does Account have fields required for Partner Account creation?
• Security: Can the actor convert Leads? Can automation user create Accounts? Can automation assign queue ownership?
• Logic: What happens when Lead Source ≠ Partner Referral? Does automation create duplicate accounts? Is the Flow Bulk-Safe?
• UI: Does the user see Partner Account after conversion? Do role hierarchies impact visibility?
• Apex/Flow: What happens on mass conversion or imports? What if conversion is triggered by API?

Each of these becomes a separate test condition.

Step 5 — Create a Clean, Structured Test-Condition List

A correct output looks like this:

Data Model

• DM01 — Lead Source picklist contains “Partner Referral”
• DM02 — All required fields for conversion must be populated
• DM03 — Account fields required for Partner creation exist

Security

• SEC01 — Actor has permission to convert Lead
• SEC02 — Automation user can create Account
• SEC03 — Automation user can assign queue owner

Logic

• LOG01 — Automation creates Partner Account when Lead Source = PR
• LOG02 — Automation does NOT create Partner Account when Lead Source ≠ PR
• LOG03 — No duplicate Account created if matching rule finds existing Account

UI

• UI01 — User can view Partner Account post-conversion
• UI02 — Visibility follows hierarchy rules

Apex/Flow

• FL01 — Flow runs in bulk conversion
• FL02 — Flow behaves consistently for API-triggered conversion
• FL03 — Error handling for missing mandatory fields

This is the correct “First Visible Layer” output.

---

Why This Method Works

Because it is aligned with:

• Salesforce architecture,
• real project constraints,
• how developers think,
• how consultants design business logic,
• how UAT users interact with the system.

Most importantly, it prevents missed defects — especially the “embarrassing ones” where something wasn’t tested simply because nobody realized Salesforce has a rule supporting it.

---

Quick Summary

• Test conditions are the foundation of all high-quality Salesforce testing.
• Visible conditions come from requirement text.
• Hidden conditions come from Salesforce architecture.
• Categorization → Actor → Visible → Hidden = complete analysis.
• Once extracted, test conditions guide test-case writing, effort estimation, and defect prevention.

02.01.05 — Extracting Initial Test Conditions (First Visible Layer)

The First Visible Layer of Salesforce Test Analysis

Before you write a single test case, before you decide which Quadrant a scenario belongs to, and before you estimate effort, you must extract test conditions.

Test conditions are the atomic facts that must be validated for a requirement to be considered correctly implemented.

They act as the bridge between:

• business language (what the client thinks they want)
• system behaviour (what Salesforce will actually do)

And this is where Salesforce testers often make their first major mistake:

They jump into writing test cases without identifying test conditions.

Without test conditions, test cases become bloated, repetitive, and unfocused.

With clearly defined test conditions, test-case writing becomes mechanical and fast.

---

What Are Test Conditions?

A test condition is a single statement of behaviour or system expectation that must be true for the requirement to be considered complete.

Examples:

• “User with Profile X can create a Contact.”
• “A validation error appears when Date < Today.”
• “Flow creates a Case automatically when Checkbox = true.”
• “Picklist values differ by Record Type.”

Each of these is a condition, not a test step.

A test case may include multiple test conditions, and one condition may appear in several test cases.

---

The Two Types of Test Conditions

When extracting the first layer, focus on identifying:

1. Visible Test Conditions

These come directly from what is explicitly written in the requirement.

Examples:

• “When Stage = Closed Won → create Contract”
• “Field X becomes required”
• “Only Managers can approve the request”

Visible conditions are usually easy — but they make up only 30–40% of what needs to be tested.

2. Hidden Test Conditions

These do not appear in the requirement text — but always exist because of Salesforce architecture.

Examples:

• CRUD/FLS access needed to perform the described action.
• Record-sharing rules that may block automation.
• Running the logic in bulk (imports, API updates, list views).
• Before/after trigger order.
• Validation rules that might block or override new logic.
• Data dependencies (related records required beforehand).

Hidden conditions are where senior testers outperform junior testers.

Visible = what business thinks the system does.
Hidden = what Salesforce will actually do.

---

How to Extract Test Conditions — The Method

This is the exact method used in consulting projects to extract complete, clean, reliable test conditions.

Step 1 — Categorize the Requirement

Use the five categories from previous lessons:

1. Data Model
2. Security
3. Declarative Logic
4. Apex Logic
5. UI

Each category automatically produces a checklist of condition sources.

Example: If a requirement touches Data Model + Security + Flow → you already know where to look.

Step 2 — Identify the “Actor”

You never use real user names. You define actors by access model:

• “Sales Rep (Profile: Sales User + PS: Opportunity Access)”
• “Back-office user (Role: Operations North)”
• “System automation user”

Each actor brings its own test conditions:

• Can they see the fields?
• Can they modify the records?
• Can they trigger the logic?

Step 3 — Extract All Visible Test Conditions

From the requirement text, rewrite every statement into a condition.

Requirement example:

“When a Lead is converted and Lead Source = ‘Partner Referral’, automatically create a Partner Account and assign it to the Partner Manager queue.”

Visible conditions:

1. Lead conversion works for actor X.
2. Lead Source has value “Partner Referral”.
3. Partner Account is created on conversion.
4. Partner Account is assigned to Partner Manager queue.

This is the easy part.

Step 4 — Derive All Hidden Test Conditions

Now the real work begins. Ask:

• Data Model: Does Lead have required fields for conversion? Is Lead Source picklist accessible? Does Account have fields required for Partner Account creation?
• Security: Can the actor convert Leads? Can automation user create Accounts? Can automation assign queue ownership?
• Logic: What happens when Lead Source ≠ Partner Referral? Does automation create duplicate accounts? Is the Flow Bulk-Safe?
• UI: Does the user see Partner Account after conversion? Do role hierarchies impact visibility?
• Apex/Flow: What happens on mass conversion or imports? What if conversion is triggered by API?

Each of these becomes a separate test condition.

Step 5 — Create a Clean, Structured Test-Condition List

A correct output looks like this:

Data Model

• DM01 — Lead Source picklist contains “Partner Referral”
• DM02 — All required fields for conversion must be populated
• DM03 — Account fields required for Partner creation exist

Security

• SEC01 — Actor has permission to convert Lead
• SEC02 — Automation user can create Account
• SEC03 — Automation user can assign queue owner

Logic

• LOG01 — Automation creates Partner Account when Lead Source = PR
• LOG02 — Automation does NOT create Partner Account when Lead Source ≠ PR
• LOG03 — No duplicate Account created if matching rule finds existing Account

UI

• UI01 — User can view Partner Account post-conversion
• UI02 — Visibility follows hierarchy rules

Apex/Flow

• FL01 — Flow runs in bulk conversion
• FL02 — Flow behaves consistently for API-triggered conversion
• FL03 — Error handling for missing mandatory fields

This is the correct “First Visible Layer” output.

---

Why This Method Works

Because it is aligned with:

• Salesforce architecture,
• real project constraints,
• how developers think,
• how consultants design business logic,
• how UAT users interact with the system.

Most importantly, it prevents missed defects — especially the “embarrassing ones” where something wasn’t tested simply because nobody realized Salesforce has a rule supporting it.

---

Quick Summary

• Test conditions are the foundation of all high-quality Salesforce testing.
• Visible conditions come from requirement text.
• Hidden conditions come from Salesforce architecture.
• Categorization → Actor → Visible → Hidden = complete analysis.
• Once extracted, test conditions guide test-case writing, effort estimation, and defect prevention.