Tomasz Teodorowicz

Lesson goal This lesson explains how Equivalence Partitioning can be applied effectively in Salesforce projects to reduce the number of test cases without reducing coverage. After this lesson, you should be able to: * identify logical partitions in Salesforce requirements, * group test conditions in a meaningful way, * avoid redundant 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

Lesson goal This lesson introduces a practical review model for evaluating the quality of test cases in Salesforce projects. After this lesson, you should be able to: * quickly assess test case quality without overanalyzing, * identify the main reason why a test case is weak, * guide improvements in a structured and

Lesson goal This lesson identifies the most common mistakes made when writing test cases in Salesforce projects and explains why they are dangerous. After this lesson, you should be able to: * recognize weak or misleading test cases, * understand why certain patterns consistently fail in Salesforce, * avoid mistakes that create false

Lesson goal This lesson explains why test cases that look correct on paper fail in real Salesforce projects and how to recognize and fix the root causes. After this lesson, you should be able to: * identify failure patterns early, * understand why “good” test cases still produce bad results, * improve test

Lesson goal This lesson explains how to define Expected Results that actually validate Salesforce behavior instead of confirming obvious UI reactions. After this lesson, you should be able to: * distinguish meaningful verification from superficial checks, * define Expected Results that validate business logic, * avoid common mistakes that reduce test value and

Lesson goal This lesson explains how to write durable step instructions that remain valid despite UI, layout, and configuration changes in Salesforce. After this lesson, you should be able to: * avoid UI-coupled instructions that quickly become obsolete, * write functional, behavior-focused steps, * separate execution mechanics from verification logic. Why step instructions

Lesson goal This lesson explains the difference between High-Level Steps and Detailed Steps and shows how to use both effectively in Salesforce test cases. After this lesson, you should understand: * why not every test case should start with detailed steps, * how High-Level Steps improve analysis, reviews, and maintenance, * and when

Lesson goal This lesson explains how to identify and define test conditions specific to Salesforce objects and fields. After this lesson, you should be able to: * recognise which object and field attributes influence system behaviour, * translate configuration details into concrete test conditions, * Avoid superficial testing that validates UI but misses

Lesson goal This lesson explains how to define test data and record state correctly in Salesforce test cases, and why weak data definitions are a primary cause of failed executions and false defects. After this lesson, you should understand: * why “existing data” is not a valid test precondition, * how record