Salesforce customisation debt is one of the most underestimated sources of QA risk in enterprise environments. Here's how to test your org comprehensively.
Salesforce is the world's most widely deployed CRM platform — and one of the most complex enterprise applications to test effectively. Organisations that deploy Salesforce without a structured quality engineering approach routinely encounter data integrity failures, automation breakages after every Salesforce release, integration failures between Salesforce and ERP or billing systems, and user adoption problems stemming from a platform that doesn't behave as configured. Quality engineering is not optional in a Salesforce programme — it's the difference between a platform that transforms the business and one that burdens it.
Salesforce presents testing challenges that standard web application testing frameworks are not designed to address. Salesforce's release cadence — three major releases per year — means the underlying platform changes whether your organisation wants it to or not. Custom configurations, validation rules, Process Builder flows and Apex triggers may behave differently after each release. The Salesforce object model — with its complex relationships between standard and custom objects, record types, page layouts and field dependencies — creates a combinatorial test space that is difficult to enumerate systematically without a structured approach.
Functional testing for a Salesforce implementation must cover: record CRUD operations across all custom and standard objects; validation rule enforcement under all edge cases; workflow rule and Process Builder/Flow automation triggering conditions; approval process routing, escalation and delegation logic; role hierarchy and sharing rule enforcement (can user A see record B?); report and dashboard accuracy against known data sets; email templates and notification triggers; and CPQ/Revenue Cloud pricing engine behaviour for organisations using these products.
Salesforce rarely sits in isolation. Integration points with ERP systems (SAP, Oracle, NetSuite), marketing automation platforms (Marketo, HubSpot), billing systems, customer data platforms and document management tools represent the most common source of production failures in Salesforce programmes. Integration testing must validate: bidirectional data synchronisation (does a record created in Salesforce appear correctly in the ERP, and vice versa?); error handling when integration partners are unavailable; duplicate detection and merge logic when the same entity exists in multiple systems; and event ordering when asynchronous messages arrive out of sequence.
Salesforce's three-annual release cadence makes automated regression testing not just beneficial but essential. Without it, every Spring, Summer and Winter release requires manual re-validation of the entire implementation — an effort that consumes weeks of resource. KiwiQA implements Salesforce test automation using Selenium with Salesforce Lightning-specific locator strategies, Provar for Lightning component testing, and Apex unit tests for business logic validation. Automated regression suites execute against Developer sandboxes after each Salesforce release, identifying breakages before they reach production.
Every Salesforce release is effectively a production change you didn't plan. Automated regression testing is the only viable way to maintain release confidence at a three-per-year cadence.
Salesforce governor limits impose hard constraints on Apex execution: 150 SOQL queries per transaction, 50,000 records retrieved per transaction, 10MB heap size. Exceeding these limits produces LimitException errors that surface as application failures to users. Performance testing validates that real-world data volumes and concurrent user loads don't trigger governor limit violations, that SOQL queries are written efficiently (using indexed fields, avoiding full-table scans), and that complex automation (triggers, flows, process builders) doesn't create performance bottlenecks at scale. KiwiQA's Salesforce performance testing uses realistic data volumes aligned with actual CRM record counts.
The most technically complete Salesforce implementation can still fail if business users reject it because it doesn't work the way they need it to. User Acceptance Testing (UAT) for Salesforce engages end users — sales reps, service agents, operations staff — in structured testing of their actual workflows before go-live. KiwiQA facilitates UAT programmes using structured test scripts that guide users through their scenarios, structured defect reporting that distinguishes genuine bugs from training needs, and feedback aggregation that prioritises genuine production risks over cosmetic preferences.