03.03.03 — Dry Run: Why Authors Should Not Execute Their Own Test Cases

Lesson goal

This lesson explains the purpose of Dry Runs in Salesforce testing and why test case authors should not be the primary executors of their own test cases.

After this lesson, you should understand:

• what a Dry Run actually validates,
• why self-execution hides critical issues,
• how Dry Runs improve both test quality and team efficiency.

What a Dry Run really is

A Dry Run is not formal test execution.

It is a controlled attempt to execute a test case by someone other than the author, before it is used for real testing.

The goal is not to find defects in the system.

The goal is to find defects in the test case itself.

Why authors are the worst executors of their own tests

Authors carry hidden knowledge.

They:

• remember what they meant,
• unconsciously fill gaps,
• skip unclear steps,
• assume missing context.

As a result:

• weak Preconditions go unnoticed,
• ambiguous steps still “work”,
• Expected Results are interpreted generously.

The test case passes, but only in the author’s head.

Salesforce amplifies this problem

Salesforce systems are highly contextual.

Execution depends on:

• user permissions,
• data state,
• automation order,
• record relationships.

An author already knows:

• which user to pick,
• which data to use,
• which warnings to ignore.

A different executor does not.

Dry Runs expose these hidden assumptions immediately.

What Dry Runs validate

A Dry Run validates whether:

• Preconditions are complete and executable
• User definitions are unambiguous
• Data requirements are clear
• Steps can be followed without guessing
• Expected Results are objectively verifiable

If any of these fail, the test case is not ready.

Dry Runs vs formal execution

Formal execution answers:

Does the system behave correctly?

A Dry Run answers:

Can this test be executed correctly by someone else?

Skipping Dry Runs often leads to:

• failed UAT sessions,
• inconsistent regression results,
• endless clarification questions.

Typical Dry Run failure patterns

Common issues discovered during Dry Runs include:

• missing permission details,
• undefined record ownership assumptions,
• unclear entry points,
• steps relying on UI labels,
• Expected Results that cannot be verified objectively.

These issues are rarely caught by authors.

When to perform Dry Runs

Dry Runs should be performed:

• after initial test case creation,
• after major refactoring,
• before delegating execution,
• before UAT handover.

They are especially important when:

• new team members join,
• external testers are involved,
• business users execute tests.

Who should perform Dry Runs

The ideal Dry Run executor:

• did not write the test case,
• understands Salesforce basics,
• follows instructions literally.

They should not:

• “fix” the test during execution,
• ask for clarifications immediately,
• assume missing context.

Confusion is valuable feedback.

Dry Runs as a quality gate

In mature Salesforce QA processes, Dry Runs act as a gate:

• test cases that fail Dry Runs are not executed,
• feedback is applied before formal testing,
• documentation quality improves over time.

This prevents low-quality test cases from reaching UAT or regression suites.

Key takeaway

• Dry Runs validate test cases, not the system.
• Authors are biased executors of their own work.
• Salesforce complexity amplifies hidden assumptions.
• Dry Runs are one of the fastest ways to improve test documentation quality.

If a test case cannot survive a Dry Run, it is not ready for execution.