Implementing shift left testing to reduce risk in your change management process

As the industry continues to evolve, test automation has shifted from being an added benefit to an organization, to a must have. In the age of digital transformation, test automation has become an essential component to improve all aspects of software development lifecycle, from cost to quality to speed. 

This necessity is especially important to project management. Where the traditional waterfall methodology employs testing at the end of the SDLC, today’s modern agile project management continually tests throughout every mini-iteration. This allows the customer to redefine the scope as they continue along the process. With waterfall project management, one can only estimate where and when the final product will end up, but agile project management has a more realistic viewpoint.  

“We’re not 100% sure where a particular project will end up,” says George Spalding, Executive Vice President at premier global consulting provider Pink Elephant. “We’re not 100% sure what it is going to look like. And we’re close to, but still not 100% sure, of when that’s going to be.” 

Despite all these uncertainties, there is one thing for certain: the customer will be satisfied. The ability to redefine the scope at every iteration provides the customer with peace of mind; customers know exactly what they don’t want as soon as you show them, and being able to identify unwanted items early on will reduce risk and improve value in the long run. 

The biggest risk in IT is always change 

Historically, the idea of change has always left both individuals and organizations feeling uneasy. There was no existing structure to build your IT shop back in the day and so teams were often making it up as they went along, resulting in the need for an IT management framework. Today, the industry identifies the three traditional ITIL change types as: 

• Standard Changes: A pre-authorized change that is low-risk and relatively common. 
• Emergency Changes: A high-priority change that must be implemented as soon as possible to resolve a major incident. 
• Normal Changes: Any other service change that is not a standard or emergency change. 

In a traditional ITIL change management process, if the request for change (RFC) is minor, the urgency will be decided by the change manager and is later reported to the change advisory board (CAB). However, if the RFC is significant, the CAB will be directly involved prior to authorization of the change. This process was rooted in tribal knowledge and in turn the was very bureaucratic, controlling, and slow. Until two years ago when ITIL 4 was released, this process was the gold standard in the industry despite every little change being subject to scrutiny, leading to wasted time and effort. 

Shifting left 

Before Agile, releases were defined as a parent change; a change made up of multiple “child” (normal) changes. This left teams with a multitude of changes that required them to be dealt with in sequence. As DevOps became an extension of Agile, the continuous delivery pipeline replaced the outdated processes of waterfall change management. In this new world of DevOps, every step in the continuous delivery pipeline could be automated, allowing tools to interoperate with one another and reduce risk as a result. 

This is aided in part due to the shift left testing approach. With this method, teams test early and often within every individual iteration, or at least through the entire SDLC, to discover errors before going into production. Having error-free code going into the production environment will enable your teams to decrease complex and costly changes and in turn reduce risk. 

The new world of Agile and DevOps 

Today, deploy and release are separated into two separate concepts. 

“Deployment in this world now means that I’m putting the finished code into the live environment, but the business doesn’t see it or isn’t able to use it yet,” Spalding explains. “It does not impact the business.” 

The goal for development teams now is to get the code, feature, or new change into the live environment so that it can continue to be tested until it’s seen as a minor switch and IT deems it fit to be deployed. The business teams are then responsible for deciding when it gets released. This allows the deployment scheduled to be untethered to the business schedule. 

The evolving risk landscape 

Despite the notion that change equals risk in IT, minor changes executed correctly can be viewed as a saving grace and implementing shift left testing in your DevOps pipeline will lead to an easier change management process.  

According to Pink Elephant, the breakdown of changes before the implementation of DevOps stood at 70% being normal changes, 10% emergency changes, and 10% standard changes. After DevOps, normal changes were reduced to 20%, emergency changes were reduced to 5%, and standard changes increased to 70%. 

Overall, the shift left approach to testing helps to ensure that any changes to existing systems in production are completed in a controlled manner. With most changes now being low-risk due to the fact they have been tested to perfection early on (such as standard changes), this bulletproofs the process and changes can be put on the “fast track” for production and be examined with less scrutiny.  

Learn more about how to embed change risk prediction into your release process in our webinar: “Automate software releases with AI-powered Change and Release Governance featuring Pink Elephant”