Articles
9/24/2024
10 minutes

Chapter 3: Testing Fun-damentals

Written by
David Brooks
Table of contents

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:

  1. Test Purpose
  2. Test Type
  3. Test Level
  4. Test Method

Test Purpose

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

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

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 Type

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:

  • Functionality – Capability (Size & Generality of Feature Set), Reusability (Compatibility, Interoperability, Portability), Security (Safety & Exploitability)
  • Usability – Human Factors, Aesthetics, Consistency, Documentation, Responsiveness
  • Reliability – Availability (Failure Frequency, Robustness/Durability/Resilience), Failure Extent & Time-Length (Recoverability/Survivability), Predictability (Stability), Accuracy (Frequency/Severity of Error)
  • Performance – Speed, Efficiency, Resource Consumption (power, RAM, cache, etc.), Throughput, Capacity, Scalability
  • Supportability – Serviceability, Maintainability, Sustainability, Repair Speed, Testability, Flexibility (Modifiability, Configurability, Adaptability, Extensibility, Modularity), Installability, Localizability

Each of these qualities ensures that your Salesforce testing covers all the bases, from functionality to performance and beyond.

Test Level

Test Level refers to the scope of testing. The generally accepted categories include:

  • Unit Testing (Feature)
  • Application Testing
  • System Testing
  • Business Process Testing

Unit Testing

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.

Application Testing

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.

System Testing

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.

Business Process Testing

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.

Test Method

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
  • API Testing
  • Integration Testing
  • Static Code Analysis
  • Compliance Testing
  • Security Testing
  • Performance Testing
  • Mobile App Testing

Functional UI Testing

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.

API Testing

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)

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

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.

Security Testing

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.

Performance Testing

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. 

Mobile App Testing

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.

Salesforce DevOps Roles and Responsibilities

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.

Product Owner (Business Analyst / Product Manager)

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.

Developer

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

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

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.

Business Users

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.

Book a demo

About The Author

SVP Evangelism

I am serial entrepreneur who has worked at 6 startups with 3 successful exits over the past 34 years in the valley.

Making DevOps Easier and Faster with AI
Chapter 5: Automated Testing
Reimagining Salesforce Development with Copado's AI-Powered Platform
Planning User Acceptance Testing (UAT): Tips and Tricks for a Smooth and Enjoyable UAT
What is DevOps for Business Applications
Copado Integrates Powerful AI Solutions into Its Community as It Surpasses the 100,000 Member Milestone
Testing End-to-End Salesforce Flows: Web and Mobile Applications
How to get non-technical users onboard with Salesforce UAT testing
DevOps Excellence within Salesforce Ecosystem
Best Practices for AI in Salesforce Testing
6 testing metrics that’ll speed up your Salesforce release velocity (and how to track them)
Chapter 4: Manual Testing Overview
AI Driven Testing for Salesforce
AI-powered Planning for Salesforce Development
Chapter 3: Testing Fun-damentals
Salesforce Deployment: Avoid Common Pitfalls with AI-Powered Release Management
Exploring DevOps for Different Types of Salesforce Clouds
Copado Launches Suite of AI Agents to Transform Business Application Delivery
What’s Special About Testing Salesforce? - Chapter 2
Why Test Salesforce? - Chapter 1
Continuous Integration for Salesforce Development
Comparing Top AI Testing Tools for Salesforce
Avoid Deployment Conflicts with Copado’s Selective Commit Feature: A New Way to Handle Overlapping Changes
From Learner to Leader: Journey to Copado Champion of the Year
Enhancing Salesforce Security with AppOmni and Copado Integration: Insights, Uses and Best Practices
The Future of Salesforce DevOps: Leveraging AI for Efficient Conflict Management
A Guide to Using AI for Salesforce Development Issues
How to Sync Salesforce Environments with Back Promotions
Copado and Wipro Team Up to Transform Salesforce DevOps
DevOps Needs for Operations in China: Salesforce on Alibaba Cloud
What is Salesforce Deployment Automation? How to Use Salesforce Automation Tools
Maximizing Copado's Cooperation with Essential Salesforce Instruments
Future Trends in Salesforce DevOps: What Architects Need to Know
From Chaos to Clarity: Managing Salesforce Environment Merges and Consolidations
Enhancing Customer Service with CopadoGPT Technology
What is Efficient Low Code Deployment?
Copado Launches Test Copilot to Deliver AI-powered Rapid Test Creation
Cloud-Native Testing Automation: A Comprehensive Guide
A Guide to Effective Change Management in Salesforce for DevOps Teams
Building a Scalable Governance Framework for Sustainable Value
Copado Launches Copado Explorer to Simplify and Streamline Testing on Salesforce
Exploring Top Cloud Automation Testing Tools
Master Salesforce DevOps with Copado Robotic Testing
Exploratory Testing vs. Automated Testing: Finding the Right Balance
A Guide to Salesforce Source Control
A Guide to DevOps Branching Strategies
Family Time vs. Mobile App Release Days: Can Test Automation Help Us Have Both?
How to Resolve Salesforce Merge Conflicts: A Guide
Copado Expands Beta Access to CopadoGPT for All Customers, Revolutionizing SaaS DevOps with AI
Is Mobile Test Automation Unnecessarily Hard? A Guide to Simplify Mobile Test Automation
From Silos to Streamlined Development: Tarun’s Tale of DevOps Success
Simplified Scaling: 10 Ways to Grow Your Salesforce Development Practice
What is Salesforce Incident Management?
What Is Automated Salesforce Testing? Choosing the Right Automation Tool for Salesforce
Copado Appoints Seasoned Sales Executive Bob Grewal to Chief Revenue Officer
Business Benefits of DevOps: A Guide
Copado Brings Generative AI to Its DevOps Platform to Improve Software Development for Enterprise SaaS
Celebrating 10 Years of Copado: A Decade of DevOps Evolution and Growth
Copado Celebrates 10 Years of DevOps for Enterprise SaaS Solutions
5 Reasons Why Copado = Less Divorces for Developers
What is DevOps? Build a Successful DevOps Ecosystem with Copado’s Best Practices
Scaling App Development While Meeting Security Standards
5 Data Deploy Features You Don’t Want to Miss
Top 5 Reasons I Choose Copado for Salesforce Development
How to Elevate Customer Experiences with Automated Testing
Getting Started With Value Stream Maps
Copado and nCino Partner to Provide Proven DevOps Tools for Financial Institutions
Unlocking Success with Copado: Mission-Critical Tools for Developers
How Automated Testing Enables DevOps Efficiency
How to Keep Salesforce Sandboxes in Sync
How to Switch from Manual to Automated Testing with Robotic Testing
Best Practices to Prevent Merge Conflicts with Copado 1 Platform
Software Bugs: The Three Causes of Programming Errors
How Does Copado Solve Release Readiness Roadblocks?
Why I Choose Copado Robotic Testing for my Test Automation
How to schedule a Function and Job Template in DevOps: A Step-by-Step Guide
Delivering Quality nCino Experiences with Automated Deployments and Testing
Best Practices Matter for Accelerated Salesforce Release Management
Maximize Your Code Quality, Security and performance with Copado Salesforce Code Analyzer
Upgrade Your Test Automation Game: The Benefits of Switching from Selenium to a More Advanced Platform
Three Takeaways From Copa Community Day
Cloud Native Applications: 5 Characteristics to Look for in the Right Tools
Using Salesforce nCino Architecture for Best Testing Results
How To Develop A Salesforce Testing Strategy For Your Enterprise
What Is Multi Cloud: Key Use Cases and Benefits for Enterprise Settings
5 Steps to Building a Salesforce Center of Excellence for Government Agencies
Salesforce UI testing: Benefits to Staying on Top of Updates
Benefits of UI Test Automation and Why You Should Care
Types of Salesforce Testing and When To Use Them
Copado + DataColada: Enabling CI/CD for Developers Across APAC
What is Salesforce API Testing and It Why Should Be Automated
Machine Learning Models: Adapting Data Patterns With Copado For AI Test Automation
Automated Testing Benefits: The Case For As Little Manual Testing As Possible
Beyond Selenium: Low Code Testing To Maximize Speed and Quality
UI Testing Best Practices: From Implementation to Automation
How Agile Test Automation Helps You Develop Better and Faster
Salesforce Test Cases: Knowing When to Test
DevOps Quality Assurance: Major Pitfalls and Challenges
11 Characteristics of Advanced Persistent Threats (APTs) That Set Them Apart
7 Key Compliance Regulations Relating to Data Storage