Tomasz Teodorowicz

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

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

Risk‑based Testing & Prioritisation 02.04 — Salesforce Testing Quadrants (Your Version) A structured, Salesforce-adapted framework for grouping test conditions, managing effort, and prioritising tests in a scalable and repeatable way. --- 02.04.01 — Why the Quadrants Work for Salesforce * Why classical ISTQB levels don't fit Salesforce

Test Objectives Creation 02.03 — Test Objectives Creation Creating strong, meaningful, and accurate test objectives is a critical skill for every Salesforce QA Consultant. A well-written test objective reduces ambiguity, clarifies scope, aligns testing with business value, and accelerates every later stage of test design. This module teaches you how

Identifying Gaps & Ambiguities 02.02 — Identifying Gaps & Ambiguities in Requirements Why Most Salesforce Requirements Are Not Testable (Yet) If you stay long enough in Salesforce projects, you will notice one truth: Most requirements arrive incomplete — and some arrive wrong. This is not a failure of Business Analysts or

When you join your first Salesforce project, you usually expect requirements to behave the way they are described in certifications, books, or ISTQB materials: clear, structured statements explaining exactly what the system should do. But Salesforce projects don’t work like that. The sooner you accept it, the better tester

01.06 – Roles in a Salesforce QA Team Salesforce projects involve more than just "testers" — they include Test Leads, UAT Leads, and support roles that define how quality is delivered. This lesson explains how these roles collaborate, where responsibilities overlap, and how testers can position themselves strategically within

01.05 – Test Levels & Testing Quadrants in Salesforce Classic ISTQB testing levels don't align well with Salesforce — the platform simply behaves differently. This lesson explains the three practical testing levels used by real Salesforce QA teams, combined with a modern quadrant model adapted for metadata-driven architecture. If