02.05.01 — Understanding SRA (Risk Classes, Complexity, Compliance) Salesforce projects vary enormously in scope, architecture, and business impact. Because of this, not all requirements carry the same level of risk — and treating every requirement equally leads to wasted effort, missed defects, and unpredictable delivery quality. The Salesforce Risk Assessment

Lesson goal This lesson explains the distinction between test scenarios and test cases in the context of Salesforce projects. After this lesson, you should be able to decide consciously how much test documentation is needed based on risk, execution model, and audience — instead of defaulting to one format. The problem

Lesson goal This lesson explains how a Salesforce test case should be structured and, more importantly, why each section exists. After this lesson, you should understand: * which parts of a test case carry most of the analytical value, * which parts are often overemphasised, * and how proper structure protects test cases

Lesson goal This lesson explains how to define users correctly in Salesforce test cases and why user definition is a common source of false test results. After this lesson, you should understand: * why users in test cases represent permission context, not people, * how incorrect user definitions invalidate test coverage, * How

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

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