03.04.05 — Choosing the Right Test Design Technique

Lesson goal

This lesson explains how to choose the right test design technique in Salesforce projects, depending on the problem you are trying to validate.

After this lesson, you should be able to:

• decide which test design technique fits a given requirement,
• avoid over-testing and under-testing,
• recognize situations where writing a test case is not the best option.

Why choosing the technique matters more than knowing techniques

Knowing test design techniques is not enough.

In real Salesforce projects, the real skill is answering:

What is the right technique for this problem?

Using the wrong technique:

• increases test volume,
• hides real risk,
• wastes effort on low-value coverage.

Good Salesforce QA is selective, not exhaustive.

Start with the question, not the technique

Before choosing any technique, ask:

• What can go wrong here?
• What would be expensive to fix after release?
• What behavior is most likely to break?

The answer determines the technique.

Choosing techniques by habit (“we always do boundary tests”) leads to noise, not coverage.

When to use Equivalence Partitioning

Use Equivalence Partitioning when:

• many inputs lead to the same behavior,
• differences between inputs are irrelevant for logic,
• permissions or record types group users into behavior sets.

Typical Salesforce examples:

• multiple profiles with identical effective permissions,
• several picklist values handled by the same automation path,
• user groups that share access level.

Do not use it when:

• behavior changes subtly between values,
• hidden automation depends on specific inputs.

When to use Boundary Value Analysis

Use Boundary Value Analysis when:

• validation rules define numeric or date limits,
• logic depends on thresholds,
• platform limits may be reached.

Typical Salesforce examples:

• discount limits,
• amount thresholds,
• date-based automation triggers,
• field length constraints.

Avoid using BVA for:

• values far from boundaries,
• logic that does not depend on limits.

Boundary testing is powerful, but only at the edges.

When to use State Transition Testing

Use State Transition Testing when:

• objects move through defined lifecycle stages,
• behavior changes based on status,
• transitions trigger automation or restrictions.

Typical Salesforce examples:

• Opportunity stages,
• Case lifecycle,
• Approval processes,
• Custom status-driven flows.

Do not reduce state-driven logic to simple happy-path tests.

Transitions are where most defects hide.

When to focus on CRUD and Permissions

Focus on CRUD and permission testing when:

• access control is business-critical,
• multiple roles interact with the same data,
• data visibility and editability vary by user.

Typical Salesforce examples:

• sales vs management access,
• read-only users,
• cross-team record sharing.

Permission defects often look like functional defects.

They must be tested deliberately.

When NOT to write detailed test cases

Not every situation requires a full test case.

Avoid writing detailed test cases when:

• behavior is trivial and stable,
• risk is low,
• exploratory validation is sufficient.

Examples:

• minor UI alignment changes,
• cosmetic layout updates,
• low-risk configuration tweaks.

Over-documentation reduces focus and slows teams down.

Combining techniques deliberately

In complex scenarios, techniques can be combined.

Example:

• Use Equivalence Partitioning to group users,
• Apply Boundary Value Analysis within each group,
• Validate State Transitions for critical paths,
• Verify Permissions at key points only.

Combination should be intentional, not accidental.

A practical decision framework

Before writing tests, ask:

1. What behavior am I validating?
2. What would be the impact of failure?
3. Which technique exposes this risk fastest?

If you cannot answer these questions, test design has not started yet.

Common technique-selection mistakes

Frequent errors include:

• defaulting to happy-path testing,
• applying all techniques everywhere,
• confusing thoroughness with quality,
• writing test cases without clear intent.

More tests do not mean better coverage.

Key takeaway

• Test design techniques are tools, not goals.
• The right technique depends on risk and behavior.
• Salesforce QA requires selective, intentional testing.
• Choosing the right technique is a senior-level skill.

Effective Salesforce testing starts with decisions, not templates.