03.04.02 — Boundary Value Analysis

Lesson goal

This lesson explains how Boundary Value Analysis (BVA) can be applied in Salesforce projects to identify defects that appear at the edges of allowed values.

After this lesson, you should be able to:

• recognize where boundary conditions exist in Salesforce,
• design test cases that target edge behavior,
• avoid missing defects hidden at data and logic limits.

Why boundary values matter in Salesforce

Many Salesforce defects do not appear during normal usage.

They appear when:

• a value is just below or just above an allowed limit,
• a date crosses a logical boundary,
• automation behaves differently at extremes.

Salesforce is full of implicit boundaries:

• field length limits,
• numeric precision,
• date-based rules,
• platform limits.

Ignoring boundaries creates false confidence.

What Boundary Value Analysis really is

Boundary Value Analysis is based on a simple principle:

Systems are more likely to fail at the edges of allowed ranges than in the middle.

Instead of testing:

• every possible value,

you test:

• the minimum,
• just above the minimum,
• just below the maximum,
• the maximum.

In Salesforce, these boundaries are often defined by configuration, not code.

Field-level boundary conditions

Many Salesforce field types impose boundaries:

Text fields

• maximum character length,
• empty vs populated behavior,
• whitespace handling.

Numeric fields

• minimum and maximum values,
• decimal precision and scale,
• rounding behavior.

Date and Date/Time fields

• past vs future dates,
• boundary dates used in automation,
• time zone effects.

Boundary testing ensures that validation rules and automation behave correctly at these limits.

Validation rules as boundary definitions

Validation rules often define explicit boundaries.

Examples:

• minimum amount required,
• maximum discount allowed,
• date must be after today.

Test cases should include:

• one valid boundary case,
• one invalid boundary case.

Testing values far from the boundary adds little value.

Picklists and allowed value limits

Picklists define allowed values, which act as boundaries.

Test design should consider:

• lowest and highest logical values,
• transitions between values,
• restricted vs unrestricted picklists.

Boundary issues often appear when:

• values change state,
• automation triggers on specific picklist transitions.

Date-driven boundaries in Salesforce

Date logic is a frequent source of defects.

Common boundaries include:

• start and end dates,
• contract validity periods,
• close date thresholds,
• fiscal period boundaries.

Testing should include:

• dates just before the boundary,
• dates exactly on the boundary,
• dates just after the boundary.

This is especially important for Flows and validation rules.

Platform and system limits as boundaries

Salesforce enforces platform limits, such as:

• maximum field length (e.g. 255 characters),
• maximum values for numeric fields,
• record limits in automation contexts.

These limits often act as hidden boundaries.

Testing them:

• validates defensive configuration,
• prevents runtime errors,
• ensures graceful failure.

Boundary Value Analysis and error handling

Boundary conditions often reveal:

• unclear error messages,
• inconsistent enforcement,
• partial saves.

Expected Results should verify:

• that the system prevents invalid input,
• that the correct rule is enforced,
• that no unintended side effects occur.

Combining BVA with Equivalence Partitioning

Equivalence Partitioning groups inputs by behavior.

Boundary Value Analysis targets the edges of those groups.

Used together, they:

• minimize test count,
• maximize defect detection,
• focus effort on risky areas.

In Salesforce, this combination is particularly effective.

Practical guideline

When designing Salesforce test cases:

• identify numeric, textual, and date boundaries,
• test values at and around those boundaries,
• avoid testing arbitrary mid-range values.

Boundary-focused tests are high value with low effort.

Key takeaway

• Boundary Value Analysis targets edge behavior where defects hide.
• Salesforce has many explicit and implicit boundaries.
• Validation rules, fields, and dates are primary boundary sources.
• Combining BVA with Equivalence Partitioning produces efficient, high-impact test suites.

Ignoring boundaries means testing only where systems are least likely to fail.