.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
セールスフォーステスト
言語
.svg)
.svg)
When we say “testing,” you say “test.”
Testing. Test!
Testing. Test!
Testing means different things to different people. So far, we’ve mostly talked about testing functionality, but there are many categories of testing to consider when working with Salesforce.
Testing in this space can feel like playing three-dimensional chess, but don’t worry — we’re here to simplify it for you. We'll break down each dimension step by step, starting with:
Let’s start with the easy one: What is the purpose of testing?
Are you testing a new feature, or are you testing an existing feature to ensure that it hasn’t been broken by subsequent changes?
New feature testing is all about making sure that a new feature works as expected. Sounds simple, right? But here’s the tricky part — it’s that phrase, “as expected.” Getting everyone on the same page—whether it's the person who wrote the requirements, the developer, the tester or the end user—can be a challenge. We’ll dive deeper into this under roles and responsibilities later.
Regression testing is the process of ensuring that a feature that was working before still works after changes. Typically, regression tests are automated, but they don’t have to be. You can also run a series of manual regression tests on important features just to be sure nothing breaks.
How do I build up a regression test library?
Building up a regression test library doesn’t happen overnight, so start small. Begin with your new features and add them to your library after every release. Over time, you’ll have a more comprehensive set of tests. And yes, it’s not practical to run every test every time — so in our chapter on Automation, we’ll cover how to pick the tests that matter most.
Regression testing automation is a journey, and the best time to get started is now.
Test types can be summed up in the catchy acronym FURPS. And yes, we know it sounds like a gastrointestinal disorder. You can almost picture yourself telling your boss, “Sorry, I won’t make it in today. I’ve come down with a case of the FURPS.”
But in reality, FURPS is a widely adopted model that originated at Hewlett-Packard. It’s used throughout the software industry to classify both functional and non-functional requirements. A little history lesson: the FURPS+ model added the "+" later to include even more attributes that were too important to leave out.
Here’s the breakdown:
Each of these qualities ensures that your Salesforce testing covers all the bases, from functionality to performance and beyond.
Test Level refers to the scope of testing. The generally accepted categories include:
Unit testing is where developers embed tests directly within their code. It’s so crucial that Salesforce mandates a minimum level of unit test coverage for any Apex code deployed to production. The idea here is to validate that a developer's assumptions are correct.
Unfortunately, some developers don’t see the full value, so they create tests that technically meet coverage requirements but don’t offer much actual testing value. Developers with a strong Testing Mindset will write meaningful unit tests because they understand the benefit of discovering bugs early.
Developers use pull requests to ensure a colleague reviews their work — kind of like your chiropractor checking if your spine’s in line. Knowing someone is looking over your shoulder encourages creating useful tests rather than “do-nothing” tests.
When all the individual features come together, you have a complete app. Application-level testing makes sure that all these pieces work in harmony. Even if each part works perfectly on its own, the app as a whole can still break down. This is where app-level testing ensures everything operates as intended.
If your Salesforce setup is like most, your environment will host multiple apps, often integrated into what is lovingly called the Happy Soup. This highly integrated system can experience unintended interactions between apps, causing system-wide defects. System testing aims to ensure that the entire system is functional, not just individual apps.
In today's cloud-based environments, business processes are rarely confined to a single system. Integration with other systems is the norm. Take a quote-to-cash process, for example: it might start in Salesforce, have orders booked in Oracle Financials, fulfilled in SAP and receivables logged back in Oracle Financials, with all other systems updated along the way. Testing each app individually won’t cut it — you need a test that validates the entire process across systems. That’s where business process testing comes in, ensuring seamless operation across platforms.
When you think of Salesforce as a point-and-click application, Functional UI testing is probably the first thing that comes to mind when you hear "Testing Salesforce." But testing isn’t limited to just UI functionality. There are several types of testing critical to Salesforce:
Functional UI testing ensures that the application and its features work as expected from the user’s perspective. It’s about making sure that, from a user's point of view, the experience is seamless and everything functions as intended.
Application Program Interface (API) Testing ensures that the APIs connected to your apps are working properly. In modern app development, many companies use a Service-Oriented Architecture (SOA), where each service is designed to perform a specific task. APIs act as communication interfaces between services, allowing them to interact and exchange data.
[Three-Letter Acronym (TLA) Alert! APIs and SOA might sound technical, so let’s simplify it.]
When a person uses Salesforce, they point and click, and data shows up in the browser. When Salesforce needs data from another system, like SAP or Oracle, point-and-click is not the most efficient way to get it. Machines use APIs to talk to each other and get the information they need. Think of APIs as the universal language between services.
Bonus concept: not all functionality is available via API. Salesforce has over 100 features with no API equivalent, so Robotic Process Automation (RPA) steps in. If you're using Copado Robotic Testing, it automates actions that should have been accessible via API.
Salesforce makes it very easy to expose their capabilities as APIs so they may be consumed by other systems, or even applications running on Salesforce. It is very likely that your application uses API calls under the covers. So, it is important to test these as well.
But API testing also overlaps with Integration Testing, which ensures that Salesforce integrates smoothly with other systems like MuleSoft or native services like Salesforce’s Outbound Messaging. Even if not labeled as API testing, it's all about making sure integrations hold up.
The bottom line? Very few Salesforce setups are standalone. With all the added capabilities like Data Cloud and Einstein, most companies have many integrations, and you need to make sure those connections stay solid.
Static Code Analysis (SCA) is another critical aspect of inspecting code. The code analysis part of the name should have been a clue!
‘Static’ refers to the fact that the analysis is not executing the code. That would be Active Code Analysis, which is what the previous two categories are all about.
SCA is simply running a program to read the source code and ensure that the developer is writing code that is readable. It’s a style thing. Are they making comments in the code so their colleagues can understand it? Are they using variable names that follow a corporate standard pattern?
Wait a minute...
Why do we even care about what the code looks like? It only matters that it works right –– right?
Well, if the code were maintained over time by the same person who wrote it, then it wouldn’t be that big of a deal. Although, as former developers, the authors know that reading your own code from years in the past can be just as difficult to understand as if someone else wrote it. That's why SCA is a form of testing that’s important for long-term maintainability.
Enterprise code is maintained by a team of developers whose members may change over the years. It’s crucial that new team members can read the code, understand its purpose and know the assumptions about the inputs and the external services it interacts with. SCA helps with this. While it’s a form of testing, think of it more like a vitamin — sure, you can skip it, but your project will be healthier if you don’t.
Compliance Testing ensures that the solution meets all privacy and regulatory requirements based on the industry and geographic region. It often overlaps with Security Testing, but the focus is slightly different. Where functional testing answers, “Does the software do what we asked it to do?” compliance testing answers, “Did we ask the software to do the right thing?”
For example, if a requirement states, “Add a field showing salary information for all employees,” that’s straightforward. But if the next requirement is to “make the field visible to everyone,” a functional test might verify that all users can see the salary info. But a compliance test would flag this as a privacy issue, ensuring that only authorized users have access to sensitive data.
Access control is a common focus in compliance testing, as it’s one of the easiest forms of testing to understand. However, it’s not uncommon for Business Analysts (BAs) to assume that the development team knows certain data should be restricted, and forget to explicitly spell it out. This is where compliance testing tools can step in and ensure that Personally Identifiable Information (PII) isn't accidentally exposed.
While Compliance Testing focuses on internal user access, Security Testing is about keeping bad actors out. And by bad actors, we’re talking hackers, not someone who butchered their lines in the last play you saw.
Security Testing includes both static and dynamic variants, as well as testing for Open-Source Software (OSS) vulnerabilities. With the rise of Generative AI tools writing code, this has become even more critical. Much of the code generated by AI is sourced from open libraries, making it more susceptible to exploitation since hackers can easily access and scrutinize the source code.
A recent study conducted by the University of Quebec revealed that out of 21 AI-generated applications, only five were secure from a cybersecurity standpoint. The rest had vulnerabilities that attackers could exploit . There are repositories of known security issues tied to specific versions of common open-source libraries, and automated tools can help ensure your company is using secure, updated versions.
What if you made a change, and an important feature still worked, but now it takes a minute to load? Or even just 10 seconds? Performance Testing addresses these issues.
You might be surprised to learn that many usability complaints stem from slow page loads. (Or maybe you’ve experienced it and aren't surprised at all.) Performance Testing should be an integral part of your Usability Testing process, conducted early in the development cycle and again before release. Just because something works smoothly in development doesn’t mean it will perform well in production when combined with other changes.
When it comes to mobile app testing, Salesforce takes a slightly different approach. While most enterprise software runs seamlessly on browsers like Chrome, Firefox, Edge, Safar, and Opera across devices, the Salesforce mobile app is an entirely different beast. It’s a standalone app, not a browser-based interface, so your regular browser-based testing won’t cut it here. If your team relies heavily on Salesforce’s mobile app, then having a specific mobile testing strategy is essential.
Mobile apps come with their own set of challenges — there are dozens of operating systems and versions, and hundreds of devices to account for. Even if you limit the scope to just Apple and Android, you still have to deal with different device types and operating system versions. This makes Mobile Testing complex, time-consuming and prone to errors.
If you're doing Manual Testing, the only way to cover all bases is to have physical phones on hand to test across all permutations of devices and operating systems. Some companies make this easier by limiting support to a handful of best-selling phones, but even then, you’ll need to stay on top of OS updates. It’s a logistical headache.
Thankfully, there are solutions. You can use emulation software on desktops or in the cloud to simulate various devices and operating systems. However, keep in mind that emulation isn’t always 100% accurate. It can be close, but it’s not a perfect substitute for real-world conditions.
Another option is to use services that offer access to physical devices over the internet. These companies purchase a wide range of devices and allow you to run tests on them remotely. Some testing tools even include this capability as part of their service, so it’s worth checking with your vendor before opting for a third-party provider.
W. Edwards Deming famously said, “Quality is everyone’s responsibility,” but what does that really mean for a Salesforce DevOps team? In practice, testing responsibilities are often divided among several key roles.
The Product Owner, often known as a Business Analyst (BA) or Product Manager (PM), plays a crucial role in specifying requirements. They are typically the Subject Matter Experts (SMEs) for the business process and are expected to be the final authority on what correct behavior looks like. Because of their deep knowledge, they are also the best testers, especially when it comes to knowing boundary conditions or edge cases.
However, they’re often so busy managing stakeholders and requirements that testing takes a back seat. Despite this, they’re invaluable for Exploratory Testing, which you’ll read about more in our manual testing chapter.
A Developer is responsible for, well, developing the application. Simple, right? On the Salesforce platform, we often differentiate between those who write code and those who build using point-and-click, also known as Low Code. But let’s be clear: they are both developers. Awesome Admins bring a wealth of knowledge and expertise to Salesforce's point-and-click tools — looking at you, Salesforce Flow! So, please, call them what they are: Developers. (Message endorsed by AAA: Association of Awesome Admins).
As the creators of the changes, developers must test their own work to determine if it's ready for production. Those writing source code are also responsible for writing unit tests to ensure proper coverage, which should be enforced by their DevOps tool.
However, developers should not be the ones making the final call on whether the code passes. It’s not about trust—though we’ve known a few sneaky developers—it’s about ensuring that the Product Owner and Developer share the exact same understanding of the requirements. Ambiguities in requirements or misinterpretations can lead to software that doesn’t match expectations. This is why the final acceptance test should be conducted by someone else.
Admins oversee the overall configuration of the Salesforce environment, ensuring that users have access to the apps they need to perform their jobs. While they may be part of the development team, their role in testing can extend beyond development. Admins play a critical part in feature testing, especially in verifying that role-based access control (RBAC) is properly configured.
When new features introduce objects, fields, reports or sharing groups, these often require updates to permission sets or other configurations. Since RBAC is deeply integrated into Salesforce apps, it's essential that admins review any changes to make sure users have the correct access. As with developers, admins who configure these features should not be the ones testing their own changes — if possible, a second admin should handle the review to ensure everything is set up correctly.
QA Testers are responsible for testing the code written by others, either manually or through automated test scripts. One of their biggest challenges is ensuring that they fully understand the requirements as defined by the Product Owner. Without this understanding, a QA Tester might incorrectly approve or reject a feature's behavior.
When QA Testers are embedded within the development team, they usually have a solid grasp of the business processes being tested. However, in many organizations, testing resources are pooled across multiple teams, which can result in testers working on software they don’t fully understand. In such cases, having clear, detailed requirements is crucial for effective testing.
Now, let’s talk about Business Users — they're not the enemy, nor just "the customer." Business users are essential team members, as they know how the software is really used in their day-to-day operations. They might not always use the software perfectly, and they may not fully understand how a new feature works, but they’re the ones who ultimately need to make it work.
Including business users in your testing strategy, especially during User Acceptance Testing (UAT), ensures that everything—provisioning, documentation, and training—is set up for success. It’s not just about testing the software –– it's also about testing the readiness of the documentation and the effectiveness of user training.
Wait, do we need to test the documentation and training?
Yes, absolutely.
Salesforce was originally designed to be as easy as consumer apps like Google or Facebook, requiring no manual to use. But as it evolved, so did the need for proper documentation and training. Salesforce recognized this by embedding tech writers within development teams as early as 2006 and launching Trailhead to facilitate learning.
Testing your app’s documentation and training process is just as important as testing the app itself to ensure everything is ready for real-world use.
.svg)
.svg)
.svg)