Language
.svg){kind=small}
.svg)
.svg)
The general answer to “Why Test Salesforce” is that testing ensures defects don’t land in the hands of the users. Unfortunately, that answer does not help justify the expense of hiring teams and establishing quality processes. So we will provide the following list of reasons to justify the expense of testing.
Testing Salesforce isn't just about catching bugs –– it's about catching them early. According to Copado’s State of Salesforce DevOps Report, which surveyed over 275 QA professionals, a staggering 92% of organizations encounter production issues due to inadequate testing. Bugs identified early in the development cycle are not only easier but cheaper to fix. Late-stage defects can cost up to 640 times more to remedy. This stark cost difference highlights the critical importance of early bug detection in slashing development expenses.
But the cost to fix the bug is not the only cost you will incur if a bug reaches production. Which leads us to the next reason.
Another compelling reason to test Salesforce revolves around minimizing downtime costs. When we think of downtime for computer systems, we often think of the system being completely unavailable –– crashed, kaput, dead as a doorknob. Thanks to advancements in Cloud Computing, however, it’s rare that systems are completely down due to hardware issues.
Typically, the most common types of availability issues stem from software problems. For instance, a glitch in the authentication services might block your access to Salesforce even though the system is technically "up." This doesn't usually affect everyone, but it can cripple the productivity of individual users or specific groups who face changes in their access rights. Even if a user can log in, losing access to a critical business process means they can't do their job.
How much does this lost productivity cost your company?
Doom and Gloom Warning!
We’re going to get a little negative for a moment, but it won’t last long! We promise.
The cost isn't just about lost user time. Imagine a customer support agent unable to assist clients, or a sales operations admin who fails to close a contract by quarter-end, causing your company to miss its financial targets. These scenarios can lead to severe repercussions, too grim to detail here.
What if a release accidentally reduced the price of your most popular product in an online store by 90% - or even 10%? This is not just hypothetical.
A Copado customer, BEFORE their Copado days, accidentally slashed the price of their most popular product by 90% during a CPQ test. They thought they were updating a sandbox but inadvertently pushed a data change to production. Yep, a mere number tweak in a single record ended up costing the company thousands before the error was spotted. Remember, defects aren’t confined to software alone –– systems like Salesforce depend heavily on data for configuration management.
Why Are Software Defects Called Bugs?
The term "bug" was popularized in September 1947 when engineers at Harvard University encountered a moth trapped in a relay of the Mark II Aiken Relay Calculator. They removed the moth and documented this as the first actual "bug" found causing an error in the system, marking the origin of the term in software.
The third significant concern is security breaches (and no, not the kind that toddlers wear, though they do offer a different sort of security). The worst-case scenarios in security testing aren't always related to functionality. Imagine accidentally deploying the wrong change to production—it could literally open the doors to hackers and expose sensitive customer information to the world. The resulting fines and repair costs make the losses from downtime seem minor in comparison.
“But security isn’t part of my remit as a Salesforce administrator” you might say. Well, hate to tell you this, but the changes your team implements can inadvertently introduce security vulnerabilities just as easily as decisions about firewalls and authentication tools.
Take this cautionary tale from a previous job: a temporary worker was able to grant himself a raise through a Salesforce Experience cloud application. This breach was the result of two simultaneous mishaps. First, an admin altered the sharing rules for an object in Salesforce, granting read/write access to everyone, including external community members. Then, the clever temp edited the URL in his browser to access a standard edit page in Salesforce — a loophole made possible by the admin's oversight. Luckily, a vigilant accounts payable clerk noticed the anomaly, and the temp’s scheme was thwarted. Crime doesn’t pay, not even in the Salesforce ecosystem!
This story underscores the importance of carefully managing Salesforce access rights when rolling out new features. Moreover, it highlights how security breaches can stem from incomplete testing.
We saved the best for last, and it's not a downer — it’s your chance to be a hero in the business. By testing Salesforce effectively, you can boost productivity across the board, from sales to support teams, increase the top line of the company’s profit and loss statement and enhance customer satisfaction.
Think of it as a ripple effect: better team morale and the gratifying sense of delivering an exceptional customer experience. It’s about being part of the team that built something remarkable, something that works just as intended, and hearing users exclaim, “Yes, I love it!” Then the Users share how much they love it, and boom!
Suddenly, your product becomes unstoppable — or at least, that's the dream, right?
Consider the famous product management analogy about car brakes. When asked what brakes are for, most reply, “To stop the car!” But the wise master corrects, “No, that is what they do. The purpose of brakes is to enable the driver to go fast.” Without brakes, you’d be stuck creeping along at a snail's pace to stay safe.
Similarly, think of testing as the brakes in your enterprise development process. Yes, testing finds bugs and prevents defects from making their way to production, but they are really for enabling automation in your software development lifecycle (SDLC). Proper testing helps you go fast!
Thanks to DevOps and test automation, Salesforce teams can adopt a continuous approach to deploying and testing software. This means admins and developers can release mission-critical apps on schedule and as often as necessary, without the need to burn the midnight oil or sacrifice weekends. Customers no longer must purchase expensive version upgrades or wait for releases to happen — they get value faster.
Unfortunately, the level of DevOps maturity varies widely among enterprise IT organizations. Even the largest corporations struggle with automation. While the most advanced Salesforce users implement a comprehensive enterprise testing strategy with a dedicated team ensuring quality across the IT stack, many have yet to integrate such thorough testing practices for their Salesforce deployments. Often, the responsibility falls to the business applications team and manual testers.
To recap the reasons for testing Salesforce:
We’ll explore the unique aspects of Salesforce testing in the next chapter, but let's wrap up this section by introducing concepts we'll discuss soon: Shifting Left and Shifting Right. Not familiar with these terms? No worries, you're about to discover their significance and why they matter right now.
Simply executing tests on completed code isn’t enough. To truly safeguard your software lifecycle and save valuable time, it’s crucial to start testing right from the planning phase. Validating your designs and assumptions early on through testing key features and full releases before their launch significantly reduces risks. An error caught early in the development cycle is invariably cheaper and quicker to rectify than one found later. This is called Shifting Left.
Why is it called Shifting Left? Because in a traditional development pipeline, the stages of development are visualized on the left, and production is on the right, with all intermediate stages in between. Therefore, "shifting left" refers to moving tests earlier in the development process.
This approach means that a developer has a test ready when they believe their work is complete. This practice, known as Test Driven Development (TDD), emphasizes the importance of clear communication about changes. Business Analysts are tasked with documenting requirements so clearly that developers can implement them without ambiguity. While straightforward for simple changes, complex features often challenge this clarity.
But wait a minute. How can you write a test before the feature is complete?
At this stage, the test doesn’t need to be fully automated. A well-defined set of manual testing instructions can suffice until the feature is fully developed. For example, a basic test might look like this:
Yep, even this simple procedure counts as a test.
One of the key impacts of Generative AI on the testing world is its capability to create tests from just a description of what the feature is intended to do. This is known as Intent-based Testing.
Intent-based testing and TDD generally test the “Happy Path” –– ensuring that the feature operates as expected under normal circumstances.
See – test professionals aren’t all doom and gloom. (Well, at least some of us aren’t.)
However, a comprehensive test plan goes further, including tests designed to find ways the feature could fail. This more rigorous testing approach will be explored further in the section on Exploratory Testing in Chapter 4.
Quick Start Action
Start designing your tests during the planning phase. This ensures that developers have a clear understanding of what completion looks like. Provide simple, step-by-step instructions to show how a user would interact with the interface successfully. This groundwork not only accelerates development but also enhances the overall quality of the finished product.
Shift Right! Wait a minute, didn’t we just talk about shifting left? Indeed, we did, but here’s why you should also consider shifting right: it's all about balance.
Why Shift Right?
Shifting right means continuing to test even after your changes have been deployed to production. Yes, pre-production testing is crucial, but it’s not the whole picture. Your Salesforce production environment and your test environment are never perfect mirrors of each other. They start diverging almost immediately after a sandbox refresh due to inevitable changes on both sides. These environments are like living entities — constantly evolving and shifting.
Many companies conduct Smoke Testing as part of their release process. This involves deploying to production and then immediately running a test suite to identify any major breaks. While this is a good start, remember, making changes in production configurations—though not advisable to do directly—can be simple. Furthermore, as we will explore in the next chapter, Salesforce Orgs often harbor unknown interactions and dependencies within their metadata, affectionately known as the "Happy Soup."
Passing a smoke test doesn’t mean you're done with that feature forever. Here are three scenarios that could still break it:
Even more doom and gloom, sorry, but these are the stark realities of Salesforce management. This is why periodic smoke testing of all critical processes is essential –– to ensure that nobody has pulled the rug out from under you.
In DevOps terminology, this ongoing vigilance is called Monitoring. The goal is to continually verify that production is running as expected, catching issues before they affect users. With Salesforce often being a tool for top executives, the last thing you want is a frantic call from the C-suite about a mess in production. It’s best if you clean it up before anyone even notices.
That is what shifting right is really about. Making sure you still have a job.
When resources are tight, you might face a choice between shifting left and shifting right. If forced to choose, prioritize shifting left to catch problems early, which generally reduces the cost and complexity of fixes. However, ideally, your resource allocation should allow for both, leveraging the early detection of shifting left and the operational assurance of shifting right.
Quick Start Action
Determine how you can add testing into your production environment. Consider the tools you already have and the potential costs of implementing new solutions. This strategic investment can safeguard your projects and ultimately, your position.
By now, you should appreciate that testing is not confined to a single phase in the development process — it's an integral part of the entire DevOps cycle. Encouraging teams to 'shift everywhere' embodies a holistic and balanced approach to software delivery. 'Shifting left' catches issues early, while 'shifting right' allows you to refine your product based on real-world use. Whether you shift left, right, or apply testing across every stage, it’s essential for optimizing efficiency and prioritizing customer value for superior user experiences.
Understanding the importance of testing leads us to the concept of developing a quality mindset, which encompasses three closely related ideas:
Adopting a quality mindset goes beyond mere financial benefits –– it boosts the morale of the entire team. When your team is building and delivering impactful features to the business at speed, they will begin to love the work they do. They will feel part of a team, like the winners of the world cup. Success breeds success.
It's said that "perfect is the enemy of good," yet a quality mindset aims for perfection in crucial aspects. This mindset equips you to prioritize what's most important and perfect those elements.
A quality mindset means you will be diligent and begin to think like a tester.
How do you think like a tester?
Unlike developers who focus on meeting requirements and achieving the 'happy path,' testers adopt a critical, unbiased perspective. They not only ensure the application works as intended but also strive to discover potential points of failure before they become actual issues. Two key phrases embody this mindset:
“It’s not enough that the application does what it should, it is equally important that it doesn’t do anything it shouldn’t.”
And they say:
“Absence of proof does not imply proof of absence.”
A quality mindset means you understand that an investment in testing is like investing in brakes for your car. It will give you the courage to fight for the budget you need to deliver an amazing product that your entire team can be proud of.
Legendary quality guru W. Edwards Deming famously stated, “Quality is everyone's responsibility.” This is particularly true in Salesforce development, where quality bridges the gap between developers and testers, eliminating the blame game and mitigating downstream issues.
Testing not only validates but also reinforces quality, serving as the pulse of every Salesforce deployment. When the entire team embraces this quality-driven culture, it eases workflows and invigorates the entire project.
So, have we convinced you why you should test?
Great! Let’s go over the special use cases of Salesforce Testing next.
Level up your Salesforce DevOps skills with our resource library.
.svg)
.svg)
.svg)
.svg)
.avif)
.avif)
.avif)
