What does it mean to “Shift Left”?

Off
Strongback Consulting

If you are at IBM InterConnect, you’ll frequently hear the phrase “shift left”. Its meaning may go over your head at first, but here is what it means.

First, take this chart:

Everyone has heard this before, but the latter in the development cycle a defect is caught, the more expensive it is to fix. In the chart above, as you move from left to right, the cost goes up. Thus, when we say “shift left”, we mean, reducing the cost of development and maintenance of software by invoking testing earlier in the development cycle.

How do we do shift left? 

The farthest left we can push is to Unit testing. Unit testing is the process of a developer creating a code to test other code. It is developer driven, but is something that can be automated as part of the build cycle. There are numerous open source and commercial unit testing solutions out there, including JUnit, cppUnit, xmlUnit, nUnit, and zUnit. Oh… you don’t know what zUnit is? Well, that is a xUnit type framework for unit testing COBOL and PL/I on the z/OS (mainframe). Yes. I you read that correct. Mainframe unit tests.  Watch the video conducted by our friend Jon Sayles for more information:

Unit testing is an amazing, misunderstood and grossly undervalued type of testing. It BY FAR is the most valuable testing that you can do. It will actually accelerate development, not retard it, which may be contrary to your initial thought.

However, unit testing may not cover every possible scenario. It certainly may not catch security, or performance testing needs, nor will it solve the overall ‘black box’, or user acceptance testing  (UAT) need. This is where commercial tools such as Rational Test Workbench, and Rational Test Virtualization Server come into play. Test Workbench can test the UI from the browser perspective and run through various scenarios with multiple data points. Service virtualization creates stubs of the dependent systems (such as MQ, or the DB2 instance) such that you can call the the system under test, without invoking the dependent systems. The stubbing features work on all systems (including mainframe) and can stub entire subsystems (MQ, DB2, CICS, etc). This lets you you truly test the software you are developing in isolation.

The next pillar to shift left is automation. Automating this into your DevOps continuous deployment pipeline such that these tests are conducted before any manual tests are conducted means spending le$$ money on regression testing, and thus catching the defects earlier in the cycle. This is shifting left.

If this sounds of interest to you, let us set up a demo or consultation and show you how it can benefit your organization.

Comments are closed.