Shift-right testing refers to performing software tests in the latter part of the development process, usually after deployment or release. It is also applied to application deployment, configuration, operation, and monitoring. It is connected to DevOps as well.
Shift-right testing is comparable to buying a product that you’ve never used before. You test if it works and fulfills its promises after using it for a while.
Read More about the “Shift-Right Testing”
Shift-right testing is just one way to go about determining whether a product works or not. Another is shift-left testing.
How Shift-Left and Shift-Right Testing Differ
To understand how the two kinds of testing approaches differ, we first need to review the software development process below.
Shift-left testing occurs before a product even gets developed. Instead of waiting for the application to be built then testing it, the development team tests it at every single step.
Using the software development process diagram above, we can say that shift-left testing starts during the requirements phase and continues on into the design and implementation stages. Shift-right testing, meanwhile, happens after the implementation phase, covering the verification and maintenance stages.
While shift-left testing anticipates issues and resolves them before progressing with development, shift-right testing looks for problems and solves them when the application is already up and running.
Reasons Why Shift-Right Testing Is Gaining Traction
While it’s ideal to identify potential issues from the get-go, that’s not always possible, making shift-right testing critical.
Unlike other kinds of testing (before development), shift-right testing accounts for the experiences of real-world users. Any program with a perfect set of quality scores may still not satisfy customers. While shift-left testing can assess client satisfaction to some degree, no one can predict how actual customers would feel and what they think about a product.
Shift-right testing also helps because going to market at the soonest time possible is a goal for all developers. That said, they may not have that much time to test for all issues beforehand if they want their product to be the market pioneer.
And given the diverse nature of today’s systems (different configurations and product combinations), testing for all potential problems will not only be very time-consuming but also next to impossible. Testing an application in the ecosystem that it was bought for would determine specific issues that may require customized solutions, making shift-right testing critical.
Concepts Related to Shift-Right Testing
Shift-right testing can be done in several ways. We named a few below.
After releasing a product, one way to improve customer experience (CX) is to add new features. But you won’t know if these features will become popular. That’s where a dark launch can come in handy.
Dark launching involves adding a new feature for only a handful of users without letting them know. You can then monitor how they are interacting and responding to the addition. You can also ask for feedback. Make sure you can quickly turn the feature off if certain users don’t respond well to them.
While dark launching tells you all about your product’s frontend, you can use canary testing for its backend. You choose which users to apply the concept to, then monitor for issues that arise in the system your application runs on. If the features introduced cause problems, turn them off.
You can learn more about canary testing from this Techslang post.
No single kind of testing works 100%. Using a combination should, however, work wonders for any developer.
That said, however, we can’t deny that shift-right testing continues to gain traction, as around 40% of companies employ the approach today.