03.01.01 — Test Case vs Test Scenario: When to Use Which

Lesson goal

This lesson explains the distinction between test scenarios and test cases in the context of Salesforce projects.

After this lesson, you should be able to decide consciously how much test documentation is needed based on risk, execution model, and audience — instead of defaulting to one format.

The problem this lesson solves

In many Salesforce projects, test documentation fails not because it is missing, but because it is misaligned with the way Salesforce solutions are built.

Teams either:

• write very detailed test cases for everything, or
• write vague scenarios and call them test cases

Both approaches create false confidence.

This lesson establishes a clear boundary between scope definition and execution control.

Definitions: scenario vs test case

A test scenario defines what should be tested.

It describes:

• the business intent
• the functional scope
• the conditions that must be validated

A scenario does not describe execution steps.

Examples:

• Create an Opportunity as Sales Rep
• Edit Account address data
• Change Opportunity Stage to Closed Won

A test case defines how the scenario should be tested.

It describes:

• user context (profile, permission sets, role)
• required data and record state
• step-by-step instructions
• expected results for each step

In short:

• Scenario = intent and scope
• Test case = controlled execution

Why this distinction matters in Salesforce

Salesforce behaviour is highly context-dependent.

The same action may behave differently depending on:

• user permissions
• record type
• existing data
• active automation
• validation rules

Without controlling this context, test execution becomes inconsistent.

Test scenarios help define where to look.
Test cases help define how to look and what exactly to verify.

Salesforce is not what you are testing

A common misconception is that QA tests “Salesforce”.

In reality:

• Salesforce is a platform delivered as SaaS/PaaS
• its internal behaviour is outside your control
• You do not validate the platform itself

What you test is:

• configuration
• declarative logic
• custom logic
• data behavior
• permission-driven outcomes

This is why Salesforce testing starts with analysis, not execution.

When test scenarios are sufficient

Test scenarios are usually enough when:

• The risk is low to medium
• The feature is well understood
• the same team executes tests repeatedly
• testing is exploratory or time-boxed
• the audience is internal (delivery team)

Typical Salesforce use cases:

• sprint testing checklists
• smoke tests
• early validation during configuration
• UAT outlines for business users

Scenarios define coverage without enforcing execution details.

When full test cases are required

Full test cases are required when:

• Business risk is high
• execution must be repeatable
• multiple testers are involved
• Testing is delegated or distributed
• results must be auditable

Typical Salesforce examples:

• pricing and discount logic
• approval processes
• permission-dependent behaviour
• integrations and data processing
• flows with complex decision logic

In these cases, ambiguity leads directly to production defects.

A common failure mode: accidental hybrids

Many documents fail because they sit between a scenario and a test case.

Symptoms include:

• steps without user context
• expected results like “works as expected”
• hidden assumptions about data and permissions

These documents cannot be reliably executed or reviewed.

Each artifact must be explicitly one thing, not an accidental mix.

Decision rule: scope vs control

Use test scenarios when you need:

• speed
• directional coverage
• flexibility

Use test cases when you need:

• consistency
• evidence
• control over execution

This is not a documentation preference.

It is a risk management decision.

Key takeaway

• Test scenarios define what to test.
• Test cases define how to test it under controlled conditions.
• In Salesforce projects, choosing between them depends on risk, context, and execution needs, not habit.

This distinction is the foundation for all further test design work in this module.