This full version of this article originally appeared on the Parasoft blog and was written by Cynthia Dunlop.
DevOps adoption across the enterprise is rising as rapidly as Northern California’s reservoirs after El Niño’s “March Miracle.”
With DevOps, the constant deluge of new functionality undeniably creates a torrential disruption to traditional testing. Many teams are barely keeping their heads above water trying to ensure that each new requirement actually works before it’s deployed. So how can you ensure every “little change” doesn’t introduce side effects that ripple across the application and make the end user more frustrated than a driver on a flooded California freeway?
Parasoft recently hosted a “DevOps is an El Niño for Software Testing” webinar featuring Kelly Looney (DevOps consultant for Skytap customers) and Wayne Ariola (Parasoft Chief Strategy Officer and co-author of Continuous Testing). Since the webinar generated such overwhelming attendance and response, we thought we’d highlight a few of the key points here.
How is software testing impacted by DevOps and Agile?
Traditionally, testing has been a time-boxed event. You’d wait for development to produce a viable build, then there was a time for QA to exercise what they needed to test. When they felt they were “done testing” or ran out of time, testing stopped.
With the rise of Agile and DevOps, two main things happened:
- The (already-shrinking) late-cycle time dedicated to exercising the application disappeared completely.
- The prevailing methods of testing (manual testing and GUI testing) became obsolete because they were too slow, time-consuming, expensive, and fragile for a world of short iterations and constant change.
To release with confidence despite the speed and frequency of today’s release cycles, we need to stop asking “Are we done testing” and shift the focus to “Does the release candidate have an acceptable level of business risk?” If we can answer this question, we can determine if the application is truly ready to progress through the delivery pipeline.
Given the rising cost and impact of software failures, organizations can no longer 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—e.g., via Continuous Testing.
What’s the difference between “Environments-as-a Service” and “Service Virtualization”?
The application stacks that are under your control (cloud-ready) can be imported and imaged via elastic cloud-based environments. Service Virtualization then allows you to simulate the behavior of those dependencies you cannot easily image (e.g., third-party services, SAP regions, mainframes, not-yet-implemented APIs, etc.), or those you want to stabilize for test coverage purposes.
The result is that IT teams or environment administrators can easily set up complete dev/test environments that testers and developers can quickly (and simultaneously) configure and provision on demand. [Learn more about how these two technologies work together]
Watch the complete “DevOps is an El Niño for Software Testing” webinar on demand
