As agile development practices mature and DevOps principles begin to infiltrate our corporate cultures, organizations realize the distinct opportunity to accelerate software delivery. However, when you speed up any process, immature practice areas and roadblocks become much more pronounced. It’s the difference between driving over a speed bump at 5 MPH versus 50 MPH … at 50 MPH, that speed bump is going to be quite jarring.
Accelerating any business process will expose systemic constraints that shackle the entire organization to its slowest moving component. In the case of the accelerated SDLC, testing has become the most significant barrier to taking full advantage of iterative approaches to software development. For organizations to leverage these transformative development strategies, they must shift from test automation to Continuous Testing. Drawing a distinction between test automation and Continuous Testing may seem like an exercise in semantics, but the gap between automating functional tests and executing a Continuous Testing process is substantial.
There are many nuances associated with the transformation from automated testing to Continuous Testing. In this post, let’s focus on three key distinctions:
The most fundamental shift required in moving from automated to continuous is aligning “test” with business risk. Especially with DevOps and Continuous Delivery, releasing with both speed and confidence requires having immediate feedback on the business risks associated with a software release candidate. Given the rising cost and impact of software failures, you can’t afford to unleash a release that could disrupt the existing user experience or introduce new features that expose the organization to new security, reliability, or compliance risks. To prevent this, the organization needs to extend from validating bottom-up requirements to assessing the system requirements associated with overarching business goals.
One of the biggest constraints associated with exercising meaningful tests is accessing a complete test environment—including the myriad dependent systems that the application under test (AUT) interacts with. Given the composite nature of today’s applications, it is nearly impossible to stage a complete test environment. This is where Service Virtualization comes into play. Service Virtualization enables you to emulate the behavior of specific components in heterogeneous component-based applications such as API-driven applications, cloud-based applications, and service-oriented architectures. By simulating the AUT’s interactions with the missing or unavailable dependencies, Service Virtualization helps you ensure that data, performance, and behavior is consistent across the various test runs. Moreover, it also helps you “shift left” testing so it can begin much earlier in each iteration and expose defects when they’re fastest and easiest to fix.
As a general rule, you should be testing against the most production-like environment that you can access …if not in production. However, this typically presents a sizable challenge in terms of cost, security, and privacy. Using simulation technologies such as Service Virtualization allows you to bypass the constraints associated with the dependent systems outside of your control in order to run meaningful end-to-end tests.
Testing at the API/message layer (services, message queues, database abstraction layers, etc.) offers several distinct advantages for enabling Continuous Testing at the speed of DevOps:
Parasoft’s industry-leading automated software testing tools support the entire software development process, from when the developer writes the first line of code all the way through unit and functional testing, to performance and security testing, leveraging simulated test environments along the way.