Transcripted Summary
Welcome back everyone! Today, we are diving into a highly debated topic in the ecosystem: standard versus custom features in Salesforce. As a Salesforce test engineer, you must thoroughly understand these two concepts and how they differ, as this is a very common topic in interviews and daily testing operations.
Let's first define Standard Features. Standard features are the built-in out-of-the-box functionalities provided by Salesforce itself. When you spin up a new developer org, sandbox, or live environment, all standard features are already there. You can easily configure them, but you cannot delete them.
Standard features include:
Standard Objects: Account, Contact, Lead, Opportunity, Case.
Standard Fields: Name, Email, Phone, Created Date.
Standard Tabs: Home, Reports, Dashboards.
Standard Security: Profiles, Roles, Permission Sets.
Standard Automation: Approval Processes.
Think of buying a brand-new car. It already comes with an engine, wheels, steering, and gears. These are your standard features. From a testing perspective, your job with standard features is to check that the existing behavior is working correctly, verify any configurations a developer has made on top of them, and perform regression testing after major Salesforce seasonal releases to ensure nothing has broken.
Now, let's talk about Custom Features. As the name implies, these are customizations created by developers or administrators to meet specific business requirements that standard Salesforce does not support out of the box. They are built on top of the standard Salesforce platform.
Custom features include:
Custom Objects:
Invoice__c,Policy__c.Custom Fields:
GST_Number__c,PAN_Number__c.Custom Components: Custom Tabs, Custom Validation Rules, Apex Triggers, Lightning Web Components, and Custom Flows.
You can easily identify custom objects and custom fields in the backend because they are appended with the double underscore "c" (__c), which stands for "custom."
Returning to our car analogy: your standard car is great, but you want to install a custom GPS, a high-end music system, and fancy custom seat covers to match your personal taste. That is customization. When testing custom features, your focus shifts heavily to functional testing, deep integration testing (ensuring the new custom components do not break existing standard behaviors), negative scenario testing, and edge cases. Because custom features are built from scratch, the risk of bugs is much higher.
Here is a quick comparison table to help you keep these straight:
| Feature/Metric | Standard Features | Custom Features |
|---|---|---|
| Provided By | Salesforce | Customer / Developer |
| Available by Default | Yes | No |
| Can Be Deleted? | No | Yes |
| Customization Level | Limited | High |
| Risk of Bugs | Low | High |
| Maintained By | Salesforce | Customer |
Understanding the limits of standard configurations versus the vast flexibility of customizations will make you a much more effective QA engineer. Thank you for watching, and happy testing!
Quiz
The quiz for this chapter can be found in 1.5.
