Ensure Oracle cloud readiness with scalable, codeless test automation
Learn how you can use codeless test automation to develop a scalable Oracle testing strategy that works before, during, and after the migration.
If there is one thing we know for sure, it is that it’s extremely difficult to accurately reproduce a production environment for QA purposes. That’s why there is such a natural pull in the direction of testing in production (TiP), in which testing is done within the live environment where real users are actively engaged in the product.
There are many benefits to using the production system as a means to conduct QA, but it can be stressful for an organization that isn’t well versed in the practice. Oftentimes, the risks of TiP prevent software testers from even trying it out. And in the worst-case scenario, a poorly managed TiP initiative can have dangerous consequences, impacting real users and revenue.
However, TiP is not something to be afraid of. The more you understand what may go wrong and how to take the proper precautions to prevent that, the more successful and efficient your overall app development process will be.
When you rely solely on a dedicated QA environment to performance test your app before launching it in production, you open yourself up to the risk that minor differences in how the QA and production environments are implemented actually have a big impact on app quality and performance. Testing in production practices can lead to great new insights — potentially avoiding catastrophic system failures.
The major benefit of TiP is the ability to test aspects of production against real users, providing a controlled way of learning how the live environment — not to mention the people operating it — behaves under specific conditions of usage, failure, and stress. Take the example of the Netflix’s Chaos Monkey, a subroutine that operates in the production environment introducing random errors like VM crashes and network interruptions. These manufactured bugs force developers to address significant error conditions and code around them. It also keeps an organization familiar with otherwise rare disaster situations that require system recovery and other operational solutions.
Other methods of TiP are used in different situations to allow you to see how small quantities of users react to a change, or how users react to two totally different products. Overall, the ability to test user and system behavior in real time is what is so attractive about testing in production.
It’s natural to be cautious, though — we understand. If you are new to TiP, you may be concerned about some of its downsides. So here are five ways to temper various forms of risk that TiP introduces into your development process.
When it comes to SaaS, users are your lifeblood. Without them there is no usage, no revenue, and no business. Obviously their experience matters above all else, so any testing we do in production simply cannot break the production environment.
In our post 7 ways to build a robust testing in production (TiP) practice, we summarized a few methods that can be used to control the impact of testing on users: canary testing (introducing small amounts of code change and see if it works) and controlled test flights (seeing how users interact with intended changes in UI) are two key examples. Synthetic users also play a huge part in TiP, as they capture metrics that show what real users would experience when executing specific transactions in your product, without requiring real users to go through those user paths.
Another form of mitigating the effects of testing on real users is an old standby — the scheduled maintenance window. It’s common to conduct load tests on a production system during low-usage periods. However, even in these situations you are still impacting the users that are on the system at that time. Take this example we encountered recently: An educational software company was conducting a 10,000 virtual user load test. They scheduled it for off-hours when only 500 real users were on the system. However, those 500 users were still exposed to the product at its worst. Here’s an example where notifying users that the system would be down for a short time could’ve protected everyone from a poor experience.
Another common concern of testing in production has to do with security. Imagine introducing a vulnerability into a system because the code you deploy wasn’t properly vetted. Or running a separate instance of your application for testing purposes on production equipment, only to discover that proper security steps weren’t followed because the operations team wasn’t completely aware of this dedicated space.
The best way to mitigate this risk is to begin the TiP process with a cross-functional mindset. You need input from your data security and Operations team to make sure you are running your tests in a safe way. As part of a mature QA process, TiP can’t be relegated to solely the domain of the QA group — instead, it must be implemented with the entire team in mind, so that it benefits the entire team. Over time, security can easily become a normal part of how the entire team approaches and implements the TiP process.
One of the reasons that modern Operations teams comprising many people can effectively manage a complex production environment is a strong system for accountability. Changes are controlled and documented, and records are kept to make sure that if any problems arise, the root cause can be identified and fixed to prevent that mistake from happening again. However, this is not necessarily as common or as rigid a practice in QA as it is in Operations.
When it comes to TiP, you need to merge common QA practices with common Operations practices. This means putting in place systems for accountability: keeping detailed notes, names, dates, and case tracking. Work with your Operations teams to find an easy, non-intrusive way of introducing appropriate change control processes into the QA procedure. As an overall rule of thumb, treat the TiP environment as the production environment and you won’t let your guard down in terms of accountability.
The issue of ownership is a hot topic when testing in production because both the QA and the Operations group may claim to own the environment. This can be even further complicated if an issue comes during a TiP run, and someone has to relay the issue back to the Development team. Now you have code that needs to be created and deployed in production, for the purposes of testing. It can be an ownership mess.
To address these concerns, build up good practices for communication and coordination across the whole team. Addressing ownership is typically less of an issue with the TiP process, and more commonly an organizational issue in the end. When the organizational roles and procedures are clear, you can begin to bridge the gap between QA and Production teams for a trusting and productive working relationship.
Lastly, testing in production can lead to cross-contamination problems. The nature of shared web services is that one may impact others, even if the applications are virtually separated, due to the infrastructure components they have in common. Put simply, conducting testing on application 1 could cause unexpected problems on application 2 for which there is no obvious root cause.
This makes it important to monitor changes and be aware of the entire backend. It is easiest to mitigate this problem by isolating each app during testing and alerting everyone involved when testing is occurring that may impact other applications. This also brings us back to how important it is to work alongside an operational team and improve site maintenance procedures in order to recover from a problem with cross-contamination.
There are many clear benefits to testing in production, and if you manage the process properly, you can counteract the major downsides of TiP without too much effort. It’s clear that security, accountability, security, ownership, and cross-contamination can pose serious risks to the process, but using sound organizational and tracking and procedures during the ever-vulnerable test period should do the trick. Happy testing!
This post was originally published in 2015 and was most recently updated in July 2021.