Does Service Virtualization’s "Shift Left" Burden Developers?

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., forcontinuous 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. 

Without Service Virtualization 

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.

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…