Welcome!

SDN Journal Authors: Liz McMillan, Yeshim Deniz, Elizabeth White, Pat Romanski, TJ Randall

Blog Feed Post

Does Service Virtualization’s “Shift Left” Burden Developers?

service virtualization shift left

Service virtualization undeniably benefits the development process, but it can be both a blessing and a curse for developers. Minimizing the burden that "shift left" can place on developers is key to achieving maximum acceleration of delivery cycles.

Service Virtualization's Shift Left Benefits the Development Process

Service virtualization’s potential to “shift left” testing is relatively well-accepted throughout the industry. With simulated test environments eliminating constraints that commonly delay or curtail testing efforts, testing can begin earlier. And, as we all know by now, the earlier you find a defect, the faster, easier, and cheaper it is to fix. Beyond that, service virtualization allows teams to test more extensively and more frequently (e.g., for continuous regression testing). 

Service virtualization’s shift left certainly yields significant benefits to the development process in terms of accelerating time to market, reducing risks, and lowering the costs associated with dev/test environment management. However, its impact on the actual development team is often overlooked.

But Does Service Virtualization Burden Developers?

In many respects, service virtualization is a gift to developers. First and foremost, it means their development and testing tasks aren’t stalled because they’re waiting for still-evolving components to be completed and/or staged test environments to be available. It allows them to create and modify “disposable” test environments on demand...without having to rely on someone else each time they need to tweak an existing configuration or access a new one. It relieves them from the minutiae involved in developing and managing effective stubs or mocks. It also enables them to access much more sophisticated behavior than stubbing or mocking can provide.

Yet, this “shift left” is not necessarily a panacea from the developers’ perspective. When you shift testing left, you also hasten the point at which QA is discovering and reporting the most defects. This means that instead of defect reports peaking during the testing phase, they peak at the development phase—which is when developers are already scrambling to implement the functionality needed to meet their development deadlines. 

service virtualization shift left

Without Service Virtualization 

 

service virtualization shift left 2

With Service Virtualization - The Shift Left

Getting barraged with defect reports during this critical phase is likely to cut into development’s time and focus on creating the innovative functionality that (you’re hoping) will set your organization apart from competition.

To understand what this shift left must feel like to developers, assume you’re expecting houseguests to arrive on Sunday evening, giving you an entire weekend to tidy up and prepare. Now, imagine that on Thursday evening they call to say they’ll be arriving Friday evening...and you have a major work deadline Friday afternoon.

So what do you do? Obviously, you don’t want to throw out the baby with the bathwater here. After all, service virtualization stands to deliver remarkable benefits and provide tremendous value to your organization as a whole.

Shift Left + Compress

The good news is that service virtualization doesn’t have to place extra burdens on development. The trick is to not only shift testing left, but also compress the defect curve. In other words, reduce the overall error injection rate so there are fewer defects to find and fix.

service virtualization shift left

Shift Left + Compress

As you can see, this “shift left + compress” strategy avoids taxing development at their most critical juncture. Even though the defect curve peaks earlier, developers are not burdened with an increase in reported defects during construction time because the peak is lower. Moreover, because there are fewer defects to find and fix across the SDLC, the team is able to complete the entire iteration significantly earlier.

To return to our analogy, this is akin to your houseguests arriving early...but now they’re planning to stay in a hotel. Because you can focus on meeting your work deadline without worrying about cleaning, shopping, etc., the early arrival isn’t nearly as stressful.

How do you reduce the overall error injection rate? Through Development Testing: synchronized application of a broad spectrum of automated defect prevention and defect detection strategies in a way that reduces development risks, time, and costs. Depending on the organization's expectations and priorities, Development Testing might include static analysis, peer code reviews, unit testing, runtime error detection, and other software verification practices.

But isn’t this just placing a different burden on development? Not if it’s implemented smartly and unobtrusively. In fact, Development Testing can actually improve productivity while reducing risks. But that’s the topic for another blog…

Service Virtualization ROI Paper service virtualization roi

Curious about what ROI your organization can achieve with service virtualization? Read Parasoft’s new 5-page Service Virtualization ROI white paper to learn about the business drivers behind service virtualization purchase decisions, as well as the substantial opportunities for ROI in terms of OpEx reduction, CapEx reduction, risk reduction, and incremental top-line revenue.

Read the original blog entry...

More Stories By Wayne Ariola

Wayne Ariola is Vice President of Strategy and Corporate Development at Parasoft, a leading provider of integrated software development management, quality lifecycle management, and dev/test environment management solutions. He leverages customer input and fosters partnerships with industry leaders to ensure that Parasoft solutions continuously evolve to support the ever-changing complexities of real-world business processes and systems. Ariola has more than 15 years of strategic consulting experience within the technology and software development industries. He holds a BA from the University of California at Santa Barbara and an MBA from Indiana University.

CloudEXPO Stories
DXWorldEXPO LLC announced today that Kevin Jackson joined the faculty of CloudEXPO's "10-Year Anniversary Event" which will take place on November 11-13, 2018 in New York City. Kevin L. Jackson is a globally recognized cloud computing expert and Founder/Author of the award winning "Cloud Musings" blog. Mr. Jackson has also been recognized as a "Top 100 Cybersecurity Influencer and Brand" by Onalytica (2015), a Huffington Post "Top 100 Cloud Computing Experts on Twitter" (2013) and a "Top 50 Cloud Computing Blogger for IT Integrators" by CRN (2015). Mr. Jackson's professional career includes service in the US Navy Space Systems Command, Vice President J.P. Morgan Chase, Worldwide Sales Executive for IBM and NJVC Vice President, Cloud Services. He is currently part of a team responsible for onboarding mission applications to the US Intelligence Community cloud computing environment (IC ...
When applications are hosted on servers, they produce immense quantities of logging data. Quality engineers should verify that apps are producing log data that is existent, correct, consumable, and complete. Otherwise, apps in production are not easily monitored, have issues that are difficult to detect, and cannot be corrected quickly. Tom Chavez presents the four steps that quality engineers should include in every test plan for apps that produce log output or other machine data. Learn the steps so your team's apps not only function but also can be monitored and understood from their machine data when running in production.
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.