When selling software, particularly complex enterprise products, we understand that a sale doesn’t end when the cash hits the bank. Post-sales support is just as important as pre-sales for customer experience. In fact, customer success is what drives revenue and there is ample data to show it. Khalid Saleh of Invesp created a fantastic infographic on this. Here are some key takeaways:
Basically, customer success is everything in sales. It means you have a good product. It means you’re getting free leads, shorter sales cycles, and higher conversion rates.
What is a key way for platform providers to increase customer success? Well, for platforms, tools, and service providers, it means that they really need to focus on onboarding. Onboarding customers to your platform means getting customers up to speed with your services so they can use your tools like pros.
It also means teaching your users how to use your APIs so they can build their own solutions in applications. A good onboarding process needs to be transparent and seamless. Developers don’t want to put their “unproven” code into production. To build these integrations effectively, developers need a safe development environment to test and get familiar with your product — a sandbox environment where they can put unproven code and try it out before it goes into production.
If you’re in the business of selling APIs, the key to sales is an efficient and compelling way to prove value to your customers. Development sandboxes are ideal for this, but what are the requirements for success?
Your customers don’t want to see unexpected bugs, inconsistent or unrealistic behavior. The expectation is that your sandbox environment undergoes the same rigorous testing as your production and QA environments do.
APIs are not simple, and developers need to get up to speed quickly in order to get familiar with your product. A well-documented API and sandbox environment is critical. Swagger and OpenAPI have become necessary in terms of documenting and defining APIs and services. Equally important is validating that the behaviors of those APIs adhere to the schema as defined in the published definitions.
Your customers are eager to get started, and not having access to their newly bought product is a significant blocker for your customer’s development and test work. Any amount of downtime can contribute to a negative experience.
In the world of PCI DSS and GDPR compliance, security can mean a lot of different things, but in the context of API sandboxes, test data rather than real customer data should be used exclusively. A sandbox should never have access to customer data, and in general, applications should be sufficiently isolated from each other.
Again, a good sandbox is crucial to customer satisfaction. There’s a reason why there are annual DevPortal awards. Organizations that put a lot of effort into good API product experience get recognition.
Sandboxes are useful but there’s a catch. You can’t simply set up a bunch of sandbox environments and expect it to work. It’s not that simple. APIs don’t do anything by themselves and require orchestration that integrates with multiple internal and external services and backend systems and provides data.
Setting up a sandbox environment for a single API means standing up the whole environment, not just a single service, and this can be difficult.
There are four key challenges for creating development sandboxes which are conveniently mapped to the above sandbox requirements – the ABCDs of sandboxes:
Simply put, a sandbox environment must be stable to be accessible and provide a positive customer experience. Organizations already struggle with their own QA environment. Maintaining and delivering 100% uptime is unrealistic and downtime leads to a bad user experience.
A sandbox environment should be a faithful representation of the real system. Initially, static responses are good for simple requests, but complex operations require some change of state and dynamic logic. What happens when a customer wants to performance or negative path testing? Complicated test scenarios can be difficult to simulate in a complex system.
Maintaining a test environment isn’t free, nor are external dependencies. The more users, the more those costs will scale. Understanding those costs and understanding the usage becomes crucial to determining the pricing or charge-back model you may want to implement for your end users.
Test data in a test environment is a lot like a coin counting machine. A coin machine takes your coins and counts them. It returns some amount of cash, but if multiple people are using the machine at the same time, nobody knows which cash is theirs. The same thing happens with shared test data in shared environments. Once data is consumed, it can’t be used for other tests unless any changes are reverted in some way, which is complex and time-consuming.
These are challenges we see here that mirror what we see in many organizations that are also looking to improve their testing and test automation practices. And frankly, the solution is rather similar.
Service virtualization is a method to emulate the behavior of specific components (virtualize these dependencies) in heterogeneous component-based applications, such as:
It’s a powerful solution when it comes to API simulation by stabilizing test environments and enabling rapid agile development. The power service virtualization brings to API and SOA testing makes it a good choice for low-cost sandbox servers.
Virtualization provides the ability:
As you can see, service virtualization really checks the boxes.
In the engagements Parasoft has done, we have observed an 80:20 rule. Some environments only require simple static responses to API calls so simple mocks are enough. Modern API gateways have very good ways to store these predefined answers, such as when the mocks are built in. If that is really all that’s needed, then service virtualization might be overkill.
On the other end of the spectrum, the environment needs to be very close to realistic. API calls require real data or actual updates to backend systems. The question arises as to whether it’s cost effective to replicate so much of the real system as virtual servers. In these cases, it may be better to use the real system or a clone.
However, in about 80% of the cases, the requirements are somewhere in between these extremes. Service virtualization is sufficient to build realistic simulations for testing and validation scenarios.
The fundamental goal of a sandbox is to validate APIs and services, usually third-party products, before integrating into your production system. However, there’s a scale of maturity of usage that we see in practices of increasing sophistication aided by tools and service virtualization.
Parasoft Virtualize provides support for these use cases along with the monitoring, analysis, and reporting required for more sophisticated sandbox usage.
An API sandbox enables a smooth onboarding experience for API and service products with the aim of improving customer success. Service virtualization reduces the complexity, cost, and risk of API sandboxes. Sandboxes need near-real services and Parasoft Virtualize offers a rich feature set to replicate this behavior quickly and reliably.
Sandboxes need to be cost efficient and service virtualization offers the sweet spot solution for creating a realistic environment. With that in mind, Parasoft Virtualize provides scalability and security to API sandboxes and offers a variety of deployment models and a modular-based approach to service virtualization and data management.
As your sophistication in sandbox development increases, service virtualization is there to scale with you and enable the next level of maturity.
Grigori Trofimov is a Solution Architect at Parasoft, providing consulting services for Parasoft’s testing solutions to prospects, customers, and partners. He has spoken at conferences recently on the topic of service virtualization and deployment of disposable environments in the cloud.