Everyone who currently lives in the Salesforce ecosystem remembers May 17, 2019. This was the day the “Multi-Instance Core and Communities Service Disruption” occurred, which rendered Salesforce orgs completely unusable, blocking core business processes for customers around the globe for days.

Your first thought may be: How could something like this happen? Then you read the Salesforce release notes and realize there was no dedicated QA testing as part of the process. Instead, Salesforce’s documented process relied on their developers to test their own work and then review it with a senior (developer) architect. There was no mention of a dedicated QA team or process. Unfortunately, in this case, their process missed a critical test scenario which would have uncovered the issue and caught it before it affected the majority of the ecosystem.

This is just one example where a dedicated QA team and process could have prevented a bad situation. This isn’t exclusively a Salesforce problem — as there are companies around the world who decide it’s easier to absorb QA into their existing team or completely skip having a QA team and/or QA processes altogether. For example, startups very rarely have QA teams or processes in place in the beginning because “everyone can test” and it’s “just an additional expense.” I’ve seen hundred-person companies with little to no QA team or QA process presence.

I’ve outlined the typical reasons (read: excuses) why companies and teams decide on skipping a dedicated QA team and process… and the associated risks

#1: “The dev team will do the QA/testing” 

This approach is one of my favorites — and most common ones — because it’s doing one of two things: creating additional work for every resource across the team or silently admitting that no one will own or do the testing. It’s usually safe to assume that resources will perform their own unit testing to some degree, but who does the larger system testing? There is an endless risk in this approach because it’s essentially an agreed-upon gray area.

In many cases it creates a scramble and headache come user acceptance testing (UAT), because no one has tested the system as an end-user or the critical business processes. This creates combativeness in the team via sentiments of “it’s not my job” or “I have enough work to do.” 

#2: “Anyone can do QA/testing”

This point often shows up after a team says they will do their own QA. While I agree that anyone can point, click, and check functionality, QA teams and processes go much deeper than that. QA is involved in the analysis of the requirement and Acceptance Criteria, finding holes while writing test cases which cover all scenarios — including the kind of negative scenarios that were missed in the Salesforce issue.

On top of functional technical testing, the QA team has the business knowledge to ensure that all use cases are adequately covered from a business point of view. Not just “does this work?” but “does it work for you, the client and the business?” QA teams provide much greater value, as they are dedicated to testing, as opposed to checking the system, which is just a quick validation that one small happy path scenario works. 

#3: “Client is responsible for testing and will validate in UAT” 

Clients are typically good at checking, but not testing deeply. This is why most projects have a dedicated UAT phase — so that clients can be walked through functionality and trained before being let loose in their new system. Many clients and their end-users are completely new to Salesforce, so it’s incredibly difficult to understand if a requirement has been met since they are not sure how to test it.

The risk here is that they don’t test adequately or deep enough, and the system goes live without really confirming that critical business processes and functionality are working. This opens up more risk within the system to significant defects in production. On top of that, missed bugs at this point hurt the trust and reputation of the implementation and severe issues may even block the client’s ability to validate the system at all.

#4: “We don’t need QA”

Although rare, this reasoning does come up from time to time and incorporates most of the above points. Generally, this occurs when a client does not have experience in the software development lifecycle and does not understand or appreciate the value of QA. The best way to explain why they do need QA is to point out that fixing issues later in the development cycle costs much more money, time, and effort.

The value of a QA team at the highest level is that issues are caught early and often, fixing them where and when it’s cost-effective and valuable. By the time a bug makes it to production, it costs a client four to five times more than if it had been caught in the build phase. 

The importance of a dedicated QA team

Doing proper QA and testing takes time, effort, and expertise. The elimination of QA only increases risks to a project, the team morale, and the overall quality of a solution. Silverline’s QA team has a defined process and success-proven methodology that is applicable not only across core Salesforce, but also across a wide array of technology and systems — including Mulesoft, Marketing Cloud, and nCino… to name a few. Additionally, Silverline employs a combination of manual and automated QA testing tools to ensure we remain on the forefront of industry trends in both.

Wherever you are in your digital transformation journey, Silverline can help.