Establishing the Test Driven Enterprise for CX & EX

When I first started writing code, I took the approach most new developers do -- full steam ahead. I just wanted to write code and get my software working. And it worked – so I added even more software to it. With each new addition, I got a little more confident. Then, when my confidence was at its peak, it broke. Tracking down all the edge cases where the software broke inside a sprawling code base was near impossible and filled with mind-numbing frustration.

It made me want to give up development for something less stressful – like air traffic control or bomb disposal. 

I bring up my own development story because it’s a microcosm for pre-DevOps enterprises. There was a time when enterprises created code just like I used to. The excitement of building new software and business solutions overtook testing – right up until there was an error. Then, developers had to look for a needle in a haystack of regression.

Today, low code/no code platforms have exploded onto the market, allowing enterprises to build at breakneck speed. The focus of many lies in the customer experience (CX), which is fueled by the employee experience (EX). Non-developers can build complex tools that improve the CX using platforms like Salesforce. However, as they develop full steam ahead, there’s a looming threat. They don’t have a development background. They’re not simply bypassing testing requirements – they don’t even know they exist. 

Today much of that testing is managed by an army of QA engineers, but they can’t test as fast as an AI system, nor can they keep up with the scale. These manual QA departments have the same challenges I had when I tried to keep up with my own development. The industry needs to be prepared to address that issue with DevSecOps principles. 

How the EX Feeds the CX, and Vice Versa  

Here’s a statistic just about every business leader and marketing team has heard before – 71% of customers expect personalized experiences from the brands they connect with. Those experiences are based on data and event triggers that allow companies to connect with their customers when they’re at the highest conversion likelihood. It’s personalization on a mass scale through data, applications, devices, and communication channels.

Of course, the key here is technology. Data provides insights that can be used to predict future behavior, automate workflows, and ensure seamless CX. But these options weren’t always within reach. Developers have always been in short supply – the Bureau of Labor Statistics expects organizations to open about 190,000 developer positions every year through 2030. This shortage acted as a barrier for many companies – until they began to address the EX of their enterprise. 

Enter low code and no code platforms. These tools abstract the code-building process into a user-friendly interface. Their use has exploded over the past few years, and Gartner now estimates that 41% of non-IT employees are using them to customize data or build technology solutions.

Salesforce is possibly the most well-known application, though it’s not used as a single solution. Instead, these citizen developers connect it with other third-party software to create customized, highly complex user stories, workflows, and events.  All of these options are designed around the EX, to make the tools easy and fun to use. 

However, it’s in that handoff where the problems lie. Low code developers don’t know the basics – or needs of testing, compliance and security controls. So they approach development with all the excitement of a new developer, but with none of the necessary knowledge.

The EX Blind Spot in Low Code and No Code 

The issue with testing in low code and no code isn’t just with the platforms themselves. It’s what happens when they’re connected. While these platforms are safe in their isolated bubble, the connections created between them open them up to additional quality, security, and compliance risks.

These tools that are built by low code developers could touch dozens of points in the enterprise ecosystems. With no testing gates in place, well-meaning but inexperienced developers could create issues that trickle system-wide, causing downtime for users, threatening user credentials, or violating data sharing agreements.

We’ve returned to that early phase of development, where we create code first and worry about testing later – if at all. We’re relying on human-delivered QA processes that lead to bottlenecks, errors, and misconfigurations. That didn’t work out well for me early in my career, and I doubt it will work any better on a mass scale. 

Building a Test-Driven Enterprise Through DevSecOps 

Testing is a building block of Agile development, DevOps and the Software Development Lifecycle (SLDC). As software development grew more complex, we realized we needed to address errors n a more proactive way. We developed ways to test software at granular levels, and across complex ecosystems. 

Functional test automation is a common EX improvement. As tests in the functional category are predictable, enterprises have moved to automate many of them, removing mundane tasks from already burdened developers. However, in the low and no-code environment, there are thousands of connections to consider. How is an enterprise supposed to manage that many tests? Some have taken a test-first approach.

Test first development, sometimes called test-driven, is a method of front-loading testing. Before a line of functional code is written, a test is created to ensure the idea works. This strategy is one that centers on use cases, or user stories. The developer establishes the requirements for these functions through testing and then implements the change.Over time, these connections come together to create a test harness that captures all those low code interactions and changes. 

I’ve always tried to educate engineering teams to know that the code they write is only half of their software, and tests are the other half. It is not abnormal to have thousands of tests for an application. Those tests are crucial for the normal operations of the software. They can save hours, significantly reduce risk and build greater resilience.

In short, they reduce release cycle time and allow products and features to get in the hands of employees and customers faster. 

Harnessing Testing in Low Code Environments

In test harnessing, the enterprise creates a latticework of automated solutions built around DevSecOps principles. We target tests that are known, where the desired outcome is predictable. We know, for example, that we need to run integration testing when we connect Salesforce with a third-party platform. So why not establish an automated solution to ensure integration testing runs every time? Then, any time anyone connects this third-party software to Salesforce, a test is run to ensure its viability. 

Testing at scale in the enterprise builds resilience and speed at a fundamental level. Release days are made obsolete as the company gains a competitive edge. This is a focus on the EX that feeds into the CX. As you make it easier for your developers to do their jobs, the solutions they create improve, which in turn enhances the customer experience. As I learned early in my career, going test first doesn’t hinder development. It builds better developers.