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 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 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 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 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

Lesson goal This lesson explains how to apply State Transition Testing to Salesforce objects and processes that are driven by statuses and automation. After this lesson, you should be able to: * identify states and transitions in Salesforce processes, * design test cases that validate allowed and disallowed transitions, * detect defects caused

Lesson goal This lesson explains how to design and execute CRUD and permission-based testing in Salesforce using an access matrix approach. After this lesson, you should be able to: * systematically validate Create, Read, Update, and Delete permissions, * identify gaps in configuration-based security, * design permission tests that scale with complex Salesforce

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

💡 The Problem: “Standard” Does Not Mean “Safe” In Salesforce, everything starts with Objects. They are the foundation of the entire data model and the primary surface where business logic, automation, and permissions collide. From a QA perspective, we work mainly with two object types: * Standard Objects (e.g. Account, Contact,

💡 The Problem: Fields Are Not Just Containers In Salesforce, a field is not just a place to store data. Its definition — data type, constraints, and default value — is the first and most important validation layer in the system. When field-level configuration is wrong or insufficient, teams often try to compensate