Next-Gen App & Browser Testing Cloud
Trusted by 2 Mn+ QAs & Devs to accelerate their release cycles

43 Salesforce test case examples with templates: UI, Apex, integration, security, regression, and more. Includes ready-to-use test case tables and a free checklist sheet.

Mehul Gadhiya
Author
June 22, 2026
On This Page
Salesforce is one of the leading CRM platforms, offering businesses tools for managing clients, customers, and prospects to streamline sales and improve profitability. This cloud-based platform provides functions such as marketing automation, analytics and reporting, customer care and support, and sales automation across Sales Cloud, Service Cloud, and Commerce Cloud, with custom apps built using Apex, Visualforce, and Lightning Web Components.
Because of this range of services and clouds, Salesforce creates substantial demand for Salesforce testing. Testing verifies that a custom app built on the platform does not affect other Salesforce functionality, and that changes are carried out according to design specifications.
In reviewing Salesforce test suites across different org configurations, the same gap shows up repeatedly: teams know which categories to test but skip writing the test cases down in a reusable, traceable format, so coverage knowledge lives in one person's head instead of a shared document.
Overview
What Is a Salesforce Test Case, and Why Write It Down?
A Salesforce test case is a documented, repeatable procedure with a unique ID, preconditions, numbered steps, test data, and an expected result. Writing it down turns coverage knowledge that usually lives in one person's head into a shared, traceable asset any tester can run.
How Are the 43 Salesforce Test Cases Grouped in This Guide?
Which Categories Come With a Ready-to-Copy Worked Example?
Five categories include a complete, filled-in test case so the format is concrete rather than conceptual: UI testing, integration testing, security testing, Apex code testing, and lead conversion testing.
What Naming Convention Keeps a Large Test Suite Traceable?
The Naming conventions for Tase cases are TC_MODULE_NUMBER, for example TC_UI_001 for the first UI test case or TC_APEX_003 for the third Apex test case. Consistency matters more than the exact format, so teams can reuse whatever convention they already follow.
Which Salesforce Test Cases Should Teams Automate First?
UI, regression, and lead conversion test cases are the strongest starting points because they run repeatedly after every release and map almost directly onto Selenium, Playwright, or plain-English authoring with KaneAI once validated by hand.
How Can Teams Run All 43 Categories at Scale?
Running every category by hand each release is a coverage-versus-time tradeoff, not a hiring problem. An AI-driven execution layer like TestMu AI plans, authors, runs, and analyzes coverage across real browsers, real devices, and custom environments to make that scale practical.
Use the categories below as a ready checklist: each explains what to test and why, and five include a fully worked test case you can copy and adapt to your own org.
The remaining categories follow the same structure once adapted: a unique ID, a clear precondition, numbered steps, the test data used, and a specific expected result.
A consistent ID naming convention keeps a large test suite traceable as it grows. The convention used in the worked examples below is TC_MODULE_NUMBER, for example TC_UI_001 for the first UI test case, or TC_APEX_003 for the third Apex test case. Use whichever convention your team already uses for other systems; consistency matters more than the specific format chosen.
To get started, use this open-source, free-to-use Salesforce test case template sheet as a living resource to track your Salesforce testing procedure: Salesforce Test Case Template Sheet.
Many of these categories surface most clearly inside a specific business process rather than in isolation: the assignment rules, status automations, and email-to-case logic that Salesforce case management depends on are a good example, since a single case record touches integration, validation rules, and workflow testing all at once.
The Salesforce test case examples below are grouped by category to help streamline coverage planning, whether the focus is UI testing, accessibility testing, or any of the 43 areas covered.
Salesforce UI testing is crucial since it ensures the system is simple to use and that the organization and style of pages, buttons, and links are appropriate and consistent.
During UI testing in Salesforce, testers thoroughly examine the system's pages, buttons, and links to ensure they are functional and properly aligned, and examine the interface's functionality across browsers and devices to ensure it is responsive and performs properly across platforms.
Here are some examples of what to involve in UI testing:
Worked example, TC_UI_001:
| Field | Detail |
|---|---|
| Test Case ID | TC_UI_001 |
| Title | Verify the New Lead button is visible and aligned on the Leads list view |
| Precondition | Tester is logged in with a profile that has Create access on the Lead object |
| Test Steps | 1. Navigate to the Leads tab. 2. Observe the top-right corner of the list view. 3. Click the New button. |
| Test Data | Standard Lead list view, default Lightning theme |
| Expected Result | The New button is visible, correctly aligned with the list view header, and clicking it opens the New Lead record form without a console error |

A test case like the one above starts as a manual check, but it is also a simple candidate for automation. Once validated by hand, the same three steps can be converted into a Selenium automation script or covered through Playwright testing, since neither the button location nor the assertion changes between runs.
What does change across releases is the underlying Lightning markup, which is where Shadow DOM handling and a Salesforce-specific locator strategy, rather than generic web automation, start to matter.
Data integrity in Salesforce testing is important because it verifies data accuracy and consistency.
During data integrity testing, testers check validation rules, data import/export functionality, and data behavior across various fields and objects to ensure data is correctly input, stored, and retrieved. Validation rules ensure the data entered meets the system's criteria, while data import/export capability is tested to confirm data can be imported and exported accurately.
Here are some points included in data integrity testing:
It is critical to have a comprehensive Salesforce testing plan and to collaborate with a team of professional Salesforce developers and testers to guarantee all components of the system are adequately verified against the required data integrity.
Most data integrity failures that reach production were technically catchable earlier, they just were not caught because the environment used for validation did not resemble production closely enough.
Customization testing ensures system adaptations such as new fields, custom objects, and custom workflows do not interfere with existing functionality and meet requirements.
During customization testing, testers confirm that custom fields, custom objects, and custom processes are functional and meet requirements, while ensuring alterations do not interfere with current functionality such as data integrity, performance, or security.
It is critical to properly test customizations to ensure they do not introduce new problems into the system and that they fulfill requirements.
Integration testing in Salesforce helps ensure the system can communicate and share data with other systems correctly, such as external databases or other platforms.
Testers validate communication and data exchange between Salesforce and other systems to ensure the connection functions properly, data is transmitted and synchronized correctly, and the integration meets requirements.
Worked example, TC_INT_001:
| Field | Detail |
|---|---|
| Test Case ID | TC_INT_001 |
| Title | Verify a new Lead created via web-to-lead syncs correctly to the connected marketing platform |
| Precondition | Web-to-lead form is configured and the marketing platform integration is active in the sandbox |
| Test Steps | 1. Submit the public web-to-lead form with test contact details. 2. Wait for the Lead record to be created in Salesforce. 3. Check the connected marketing platform for the corresponding contact record. |
| Test Data | Name: Jordan Test, Email: [email protected], Company: TestMu AI |
| Expected Result | The Lead record appears in Salesforce within the expected sync window, and the same contact appears in the marketing platform with matching field values and no duplicate records created |
Security testing ensures the system is secure and meets industry standards, checking user access control, data encryption, and regulatory compliance.
Testers verify that user access control, data encryption, and industry-standard compliance are all working properly and effectively, and that the system can handle and respond to security threats such as hacking attempts, unauthorized access, and data breaches.
Worked example, TC_SEC_001:
| Field | Detail |
|---|---|
| Test Case ID | TC_SEC_001 |
| Title | Verify a user without Opportunity read access cannot view Opportunity records via direct URL |
| Precondition | Test user is assigned a profile with no access to the Opportunity object |
| Test Steps | 1. Log in as the restricted test user. 2. Obtain a valid Opportunity record ID from an authorized user. 3. Navigate directly to that record's URL. |
| Test Data | Test user profile: "Restricted Sales Rep" with Opportunity object access removed |
| Expected Result | Salesforce displays an insufficient privileges error page and no Opportunity field data is rendered or exposed in the page source |
It is essential to extensively evaluate the system's security to ensure it can manage and respond to threats efficiently and fulfills industry standards, helping identify vulnerabilities before they reach production.
Performance testing assures the system can manage anticipated usage and function well under various loads and conditions.
Testers verify the system can handle various loads, a large number of users, significant data volumes, and complex transactions, to ensure it can meet user needs.
Performance testing is crucial because it evaluates whether the system can handle anticipated usage and function efficiently under various conditions, helping locate performance bottlenecks before they affect real users.
Cross browser testing of Salesforce applications assures the CRM works well and is easy to use across various browsers and mobile devices.
Testers verify the system's functionality works appropriately on mobile devices and that layout and style remain consistent.
A major challenge with cross browser testing of Salesforce applications is building and maintaining the infrastructure to cover every browser and OS combination a customer base actually uses, rather than the two or three a team happens to have installed locally.
Salesforce testing must include load testing to ensure the system can support the anticipated volume of users and transactions and function effectively under pressure.
Stress testing assures the system can withstand and recover from unexpectedly high loads.
Testers simulate extreme usage situations to assess the system's ability to manage and recover from unforeseen scenarios, such as network outages, while retaining data integrity throughout.
Regression testing is essential since it guarantees system changes such as updates and releases do not damage existing functionality and the system keeps functioning as intended.
Salesforce testing must include User Acceptance Testing (UAT) to confirm that the system meets business requirements and is ready for release to end users.
During UAT, testers validate key areas including functionality, usability, performance, security, data accuracy, integrations, and the completeness of supporting documentation such as user guides and manuals.
To ensure UAT reflects real-world usage, testing should be performed in a dedicated UAT environment that closely mirrors production. The UAT environment should contain masked production-like data volumes, fully operational integrations, and clearly defined entry and exit criteria. This enables users to identify data integrity issues, process gaps, and potential release risks before the solution is deployed to production.
UAT is performed by end users or a UAT team comprised of end users, stakeholders, and business analysts, and is critical to ensuring the system meets requirements before release.
Disaster recovery testing ensures the system can handle and recover from unforeseen events.
Testers simulate disasters such as power outages, network failures, and hardware failures to assess recovery capability, and confirm the disaster recovery plan maintains data integrity and functionality throughout.
Accessibility testing makes sure Salesforce is usable by people with disabilities and complies with ADA and WCAG accessibility standards.
It confirms compliance by validating usability with assistive technologies such as screen readers and keyboard-only navigation.
The process can be improved through automated accessibility testing using tools like axe and WAVE, combined with manual accessibility checks to identify usability issues that automated tools may not detect.
Apex code testing is a technique for checking the functionality of individual pieces of code, such as Apex classes and triggers.
In Salesforce testing, Apex test classes are used for unit testing: collections of methods that execute test procedures examining a specific aspect of the class under test.
The ideal approach for an Apex test class is to test all potential scenarios, including positive and negative cases, with a test method for each method in the class under test, for example verifying a method correctly accepts both valid and invalid input such as null values or wrong data types.
Salesforce's built-in test runner, accessed from the Developer Console, executes Apex code testing and provides full details on tests run, passed, and any failures. Additional tools like the Apex Test Execution page and Apex Test Execution History support managing test methods, viewing results, and analyzing code coverage.
Worked example, TC_APEX_001:
| Field | Detail |
|---|---|
| Test Case ID | TC_APEX_001 |
| Title | Verify the LeadAssignmentTrigger correctly assigns a new Lead to the matching territory owner |
| Precondition | Territory assignment rules are active and at least one territory owner is configured in the test class setup |
| Test Steps | 1. In the test class, instantiate a new Lead record with a State field matching a configured territory. 2. Insert the Lead using Test.startTest() / Test.stopTest(). 3. Query the Lead's OwnerId after insert. |
| Test Data | State = 'California', matched to Territory Owner 'Pacific Region' |
| Expected Result | System.assertEquals confirms the Lead's OwnerId matches the expected territory owner's user ID, and the test class achieves at least 75% code coverage on the trigger |
Salesforce also provides additional testing options such as Asynchronous Testing and Testing Web Services, which can be evaluated to determine which fits the organization's Apex code best.
SOQL and SOSL are Salesforce query languages used to retrieve data; SOSL searches across several objects, while SOQL obtains data from a single object.
SOQL and SOSL testing verifies these queries operate properly and produce desired results, checking query syntax, running them through various filters and conditions, and confirming returned data is correct.
Apex test classes can run SOQL and SOSL searches and confirm the results line up with expectations, and third-party tools like SOQL Tester offer a user-friendly interface for running and inspecting queries.
It is important to test queries under various conditions (different filters, conditions, and data types) to verify they are operating properly and producing the desired results.
Sandbox testing is the practice of testing system modifications in an environment separated from production, letting teams validate changes before deployment.
This ensures the system operates as intended, prevents unexpected impacts on production, and provides a secure environment for experimentation, validation, and user training.
Various types of Salesforce Sandboxes are available, including Full Sandboxes, Partial Copy Sandboxes, and Developer Sandboxes, each designed for different testing needs and data refresh cycles. A Developer Sandbox supports individual development and debugging activities, while a Full Sandbox provides a near-complete replica of the production environment.
It is essential to test all aspects of the system, including data, customizations, workflows, and integrations, in a Sandbox environment that closely matches production. This helps verify that changes are implemented correctly and that the system remains stable and reliable. Security considerations can also be supported through isolation practices similar to concepts used in browser sandboxing, where environments are separated to reduce potential risks.
Salesforce release testing checks a new version of the platform before it is made available to end users.
It confirms the new version contains no new issues, does not break existing features, and remains compatible with current customizations and integrations.
Salesforce releases are classified into major, minor, and patch releases. Major releases add new features and introduce significant platform changes, while minor and patch releases focus on smaller enhancements, updates, and bug fixes.
Release testing requires a dedicated testing team and a detailed test strategy, with a test plan listing the test cases to be executed and expected results. The testing scope should cover new features, customizations, integrations, and regression scenarios.
Salesforce test automation helps teams validate releases faster by improving test coverage, consistency, and repeatability. Automated testing tools can further accelerate this process while maintaining accuracy, and it remains critical to test the release in an environment that closely matches production.
Three platform releases a year is exactly where most Salesforce test suites accumulate maintenance debt, including locators that point to renamed fields, validation rules that shift, and Lightning components that re-render differently.
Whether that debt becomes manageable or compounding depends less on which Salesforce test automation tool a team picks and more on whether the framework around it, including data management, CI/CD processes, and locator strategy, is built to support seasonal releases rather than only the current version.
Data migration testing moves data between systems or Salesforce versions, ensuring it stays correct, consistent, accurate, and accessible in the new system.
A clear test plan covering data accuracy, consistency, and accessibility should be in place before performing data migration testing, ideally executed in an environment as close to production as possible.
Backup and restore testing verifies Salesforce data can be correctly backed up and restored, and that the procedure is dependable and efficient.
Test cases should simulate scenarios like backing up and restoring specific data sets, and evaluating the restore process with full, incremental, and differential backups. It is also critical that backups are stored securely and can be restored during a disaster, including testing the disaster recovery plan itself.
Rollback testing determines the system's capacity to retract changes or undo earlier operations.
It verifies the ability to roll back data, configuration, or code changes, so the system can be restored to its previous state and faults fixed promptly if necessary.
Test cases should evaluate rolling back data changes, configuration changes, or code changes, and test the rollback process across production, development, and staging contexts. This gives the organization confidence the system can be readily rolled back to a stable state if serious difficulties arise.
Error handling testing discovers and corrects system issues by testing scenarios and user inputs across data validity, user permissions, and system integrations.
This ensures the system works properly and users can complete their jobs without issues. Salesforce provides tools like Apex Test Classes and Test Coverage to assist in testing and debugging code, alongside error messages and troubleshooting resources for users.
This is accomplished by creating test users with varying permission sets and roles, then simulating scenarios to verify the system correctly enforces access rights at the record, object, and field level.
Salesforce provides the Permission Set and Profile objects for managing and testing user rights, and the runAs() method in Apex code to verify permissions programmatically.
Role hierarchy testing ensures data security and access control work properly inside the organization.
A role hierarchy groups users by job function or position to establish each user's level of data access, users at the top, such as executives, have full access, while entry-level employees access only a subset.
Salesforce includes the Role object and the Apex UserInfo.getUserRoleId() method for managing and testing role hierarchy, alongside Sharing Rules for sharing records with specific groups or roles,these sharing rules should also be tested to ensure data is shared according to established rules.
Customizable forecasting testing verifies Salesforce's forecasting feature, which lets users create and manage sales forecasts and can be configured to meet specific needs.
Salesforce provides the Forecasts tab, Forecast Hierarchy, and Forecast Quotas objects for managing and testing this, alongside methodologies like Rolling Forecast and Opportunity Splits.
It is also essential to assess the forecasting feature's integration with reports, dashboards, and other objects, to confirm forecasts are accurately displayed and accessible.
Lead conversion testing verifies how the system manages converting leads into accounts, contacts, and opportunities.
This is critical for businesses using Salesforce to manage their sales pipeline, ensuring leads are correctly turned into customers and relevant information is gathered and tracked.
Salesforce includes the lead conversion wizard and lead conversion triggers for managing and testing this process, alongside options like "Convert and Edit" and "Convert and Close" that can be evaluated for fit.
Worked example, TC_LEAD_001:
| Field | Detail |
|---|---|
| Test Case ID | TC_LEAD_001 |
| Title | Verify converting a qualified Lead creates linked Account, Contact, and Opportunity records |
| Precondition | A Lead record exists with status "Qualified" and all required fields populated |
| Test Steps | 1. Open the qualified Lead record. 2. Click Convert. 3. Confirm or edit the auto-mapped Account, Contact, and Opportunity details. 4. Click Convert to finalize. |
| Test Data | Lead: Mr. ABC, Company: TestMu AI, Status: Qualified |
| Expected Result | A new Account "TestMu AI", Contact "ABC", and Opportunity are created and linked correctly, the original Lead status updates to Converted, and all field values carry over without data loss |
The same conversion logic above is also where teams first try natural-language test authoring, since the steps map almost verbatim onto a plain-English description, which is what makes automating Salesforce lead generation with KaneAI a practical next step once this test case is validated manually.
Data import and export testing verifies data export and import from and into Salesforce, guaranteeing data is correctly transported and relevant data is gathered and tracked.
Salesforce includes the Data Import Wizard, Data Export, and Apex Data Loader for managing this, alongside options like Standard and Custom Objects and Reports and Dashboards.
Testing involves creating test data and recreating scenarios across diverse data kinds, file formats, and data quantities to confirm the system handles export and import correctly.
Testing validation rules verifies the rules used to guarantee data entered into the system is correct and complete before saving a record.
This includes testing for various input values, user activities, and system conditions, and testing the integration of validation rules with reports, dashboards, and other objects.
Trigger testing verifies Apex triggers used to automate Salesforce system actions, improving data integrity and consistency.
Triggers are tested by creating test data and simulating scenarios across various input values, user behaviors, and system states, including their integration with other Salesforce features to ensure no unexpected results occur.
Testing workflows evaluates the actions and rules used to automate Salesforce functions, such as email notifications, field updates, and task assignments.
Workflows are managed and tested using Workflow Rules, Approval Processes, and Flow Builder, verified by creating test data and simulating scenarios across various input values, user behaviors, and system states.
Email service testing verifies the services used to send automated emails from Salesforce, such as alerts, notifications, and confirmations.
These services help improve communication with clients and stakeholders, and tools like Email Services, the Apex Email Service, and the Single Email Message support managing and testing this.
Custom test cases validate Salesforce-specific configurations, components, and business requirements to ensure custom features, objects, and settings function correctly and support user needs.
Testing custom settings verifies the configurations, user preferences, or business logic used to store custom data in Salesforce, a feature that helps administrators store and hierarchically manage custom data, improving system flexibility and scalability.
Custom label testing verifies the labels used to hold custom text such as application messages, error messages, or field labels, enabling centralized management of custom text and improving internationalization and scalability.
Testing custom objects verifies the objects used to store unique application, user, or business data, enabling administrators to manage custom data in a structured manner and increasing system flexibility.
Testing custom permissions verifies the permissions used to restrict access to specific data or functionality, supporting custom profiles, managing user access, and protecting sensitive data.
Testing custom tabs verifies the tabs used to offer access to unique objects, Visualforce pages, and other custom components, making it simple for users to navigate custom data and functionality.
Testing custom metadata verifies the values used to store custom configuration settings, validation rules, or custom labels referenced across the Salesforce application.
Testing Lightning components verifies the components used to create custom user interfaces and interactions in Salesforce.
These components can be quickly incorporated into the platform to build unique pages, forms, and other UI elements.
Verifying Lightning components requires generating test data and simulating scenarios, including:
Salesforce offers tools including the Lightning App Builder, the Lightning Component Library, and the Lightning Component Test Framework to manage and test Lightning components.
Testing Visualforce pages verifies pages used to build unique user interfaces and interactions in the Salesforce system.
The framework lets developers design custom pages and other system-integrable components.
Tools including the Visualforce Developer Console, Apex Code, and Visualforce Page Test Framework support managing and testing Visualforce pages.
To get started, use this open and free Salesforce test case template sheet as a reference to stay current on the testing process: Salesforce Test Case Template Sheet.
Running 43 categories of test cases by hand, every release, across every browser a customer base uses, is not a staffing problem most teams can solve by hiring more testers; it is a coverage-versus-time tradeoff that only changes with the right execution layer underneath it.
TestMu AI (Formerly LambdaTest) is a Full Stack Agentic AI Quality Engineering platform built for exactly that tradeoff: AI agents plan, author, execute, and analyze test coverage across web, mobile, and enterprise applications like Salesforce, at scale, across real devices, real browsers, and custom environments. Applied to the categories above, that includes:
Salesforce testing is an essential step during the development and deployment of Salesforce applications. It helps ensure an application meets business requirements, is free from bugs, and functions as expected, giving quality assurance that improves the likelihood of fast user adoption.
This guide covers all major test case categories required during Salesforce testing, with worked examples for the categories teams ask about most. Test case templates matter because they help the system work as intended and remain maintainable over long periods, improving the overall user experience and making it easier for testers and developers to manage the platform.
Author
Mehul Gadhiya is a Community Contributor with experience in creating content and strategies around software testing, automation, and emerging technologies. At TestMu AI, he has worked on initiatives spanning product messaging, sales enablement, and lifecycle campaigns, supporting testing solutions like KaneAI and HyperExecute. He has also contributed to community-focused efforts, including the Testμ Conference, building awareness and collaboration across the QA and developer ecosystem
Did you find this page helpful?
More Related Blogs
TestMu AI forEnterprise
Get access to solutions built on Enterprise
grade security, privacy, & compliance