In the past, the application and software development process followed a “waterfall” process. The software was built by the development team before it was then tested and released to the public.
Today, with the advent of microservices and organizations looking to push new software and application features out to users faster than ever before, this process of designing and then testing can no longer keep up. Especially if problems are found in testing that then have to be kicked back to developers to mediate.
Instead, many development teams are shifting the testing of applications to the left – during the development process – to ensure that application and software production can keep pace with the speed of innovation.
While this idea of testing while developing may seem foreign – or even reckless – to some, Dave Farinelli, a senior software engineer with almost a decade of experience providing enterprise-level software solutions to the healthcare and insurance marketplace, claims that it can be both safe and beneficial. In an article that Dave recently contributed to the Cloudbees blog, he lays out three key benefits that shifting testing to the left can deliver to the application and software development process.
Dave’s benefits for testing in production include:
Providing greater testing accuracy on deployments
When it comes to testing new functionality, there’s no better way to do so than testing in the same environment that’ll be used. This is especially true when doing testing in lower environments, which tend to come with either non-exact data or differences in configuration. This can result in erratic production deployments when transitioning between environments.
If you test in production, you’ll have confidence knowing your users will experience the same functionality that was verified in testing.
Enabling more frequent deployments
To be able to test in production, it requires a change in the general mindset of how deployments work. Gone are the days of months between deployments, with many features included in each deployment.
These kinds of deployments inherently bring a lot of risk, and many times end up with the “good enough” cause, finding bugs early on that take months to patch in the next deployment.
With more frequent deployments, you’ll be more agile to react to customer demand, deploying changes as needed. Frequent deployments allow for flag-driven development, meaning development will be done with the mindset of having a feature flag that turns on the functionality when appropriate.
Done correctly, this means a developer doesn’t need to worry about functionality “leaking” into higher environments, even if the functionality isn’t complete.
Allowing for a seamless transition between testing phases
Testing in production allows in itself expands the definition of testing. Instead of testing being a “does this work or not” scenario, testing expands to include “testing” the response of a particular feature.
For example, we may want to try a different UI. We can use the testing in production methodology to first test functionality via QA. After verification, we can use real customers alongside A/B testing to collect data on the response to the new functionality.
In a future article on the GovDevSecOpsHub, we’ll feature some challenges that Dave anticipates development teams will face as they look to shift testing to the left, and some best practices in which to do so.
