Tomasz Teodorowicz

Lesson goal This lesson explains why Field-Level Security (FLS) is the ultimate authority on field access and how UI configuration can create dangerous false assumptions during testing. After completing this lesson, you should be able to: * understand how FLS interacts with Page Layouts and Lightning Pages * identify common UI illusions

Lesson goal This lesson explains how to test CRUD permissions in Salesforce correctly, focusing on effective access rather than configuration assumptions. After completing this lesson, you should be able to: * design CRUD test cases for Salesforce objects * validate access across Profiles, Permission Sets, and Sharing Rules * identify high-risk CRUD misconfigurations

Lesson goal This lesson explains how Salesforce security layering really works and why QA must test effective permissions, not configuration in isolation. After completing this lesson, you should be able to: * understand the relationship between Profiles and Permission Sets * identify common conflict and override scenarios * design security test cases that

Lesson goal This lesson explains why Record Types must be treated as logic drivers, not just UI selectors. After completing this lesson, you should be able to: * identify where Record Types influence system behavior * design test cases that validate both execution and exclusion paths * avoid common QA mistakes related to

💡 The Problem: Relationships Define Behavior In Salesforce, relationships are not just links between objects. They are behavioral switches that define how data behaves when records are deleted, who can see related records, and what kind of automation is possible. The chosen relationship type directly affects: * data integrity * security and sharing

💡 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

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

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

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