Shift Right testing – background and history

The history of Shift Right testing

How the need for faster releases drives Shift Right thinking

Successful companies are able to launch new features continuously, allowing them to respond to customer demand. Doing this successfully requires you to Shift Right. This blog looks at the background to Shift Right and compares it with Shift Left.

Introduction

For several years all the talk in the world of testing has been about “Shift Left”. Indeed, we published a blog on this topic just last year. However, nowadays what matters is DevOps, continuous deployment, and rapid roll-out of new features. This implies a need to “Shift Right”. In this 2-blog miniseries, we explain Shift Right and look at the skills and tools you need to achieve it. We will also discuss the apparent tension between Shift Right and Shift Left. But first, let’s look at how we got here in the first place.

Background

How we got to where we are

The traditional development model went through a series of discrete steps from design to production. First, you defined what the product needed to achieve. Then you designed how it would achieve this. These designs were passed to developers, who wrote the code to implement the product. This code was then passed to testers who checked that it achieved the requirements and was bug-free. Finally, the code was released to production. Essentially, every stage existed as a silo, and every person had very specific skill-sets related to their particular silo.

Over the years, people have recognized that this approach to development is too inflexible. There have been numerous efforts to break down the silos and to try and streamline the process. We have written about a few of these approaches recently, such as Test-Driven Development and Continuous Testing. However, even in the agile development model, skills tend to be siloed, with testing happening at a specific stage. This is driven by the mantra that you mustn’t ever release broken and buggy code. In turn, this means testing must act as the “gate” between development and production.

Shift Left

The precursor to Shift Right

For the last decade, there has been a push towards Shift Left. This brings benefits including saving time and resources, reducing bugs and producing working prototypes.

In the 1950s, people knew that it made sense to test as early as possible. In those days, runtime resources on mainframes were extremely valuable. Coders had to make sure their code contained few errors as these were so wasteful and expensive. So, they didn’t hire people to be testers, they developed their own code and tested it properly themselves.

But then there were a few decades when pieces of software began to grow and began to need huge teams to work on them. The concept of software engineering was born, and with that came a drive to adopt traditional engineering project management. The upshot was the waterfall model, with testing firmly placed as the penultimate stage of the product development process. 

But once software became more complex still, it became apparent that leaving testing to the end is a bad idea. So, we saw a push to get testing shifted earlier in the development process. Developers are encouraged to test their own code, functions are modularized, and testers are often embedded with the developers. Thus, Shift Left was (re-)born.

What are the benefits of Shift Left?

There are some obvious benefits to Shift Left. Firstly, shifting the testing phase will enable you to spot problems earlier on. So, you can continuously work on improving your software as it’s developed, rather than waiting until the final phase. This perfectly captures “responding to change over following a plan” in the Agile Manifesto. If you don’t Shift Left, problems with the software and design only appear late in the process. This makes it harder to rectify any big mistakes, and it usually costs a lot as well. Also, the earlier you find a problem, the more efficiently the developer will fix it.

Secondly, Shift Left means you’re more likely to find all the problems in your software. Testing multiple times at every stage in the workflow gives more opportunities to spot problems. Testing at the very end means you often only have time for one set of tests. This increases the risk of releasing buggy software, which in turn leads to unhappy customers. 

Thirdly, in order to be able to Shift Left, you have to concentrate on creating working code. This means that you will be able to see how the product is developing as you go. If your software doesn’t have any functionality, it can’t be tested. Again, this captures a key concept from the Agile Manifesto. Namely, “working software over comprehensive documentation.” 

So, finding problems early on can and will significantly reduce the cost of the overall project. It is a more efficient use of time and resources and usually will improve efficiency. It gives more opportunities to spot problems before release, and the whole team will be familiar with the product. Finally, it encourages the idea of developing functional code from the start, which brings a whole raft of benefits.

The drive for faster delivery

Until the last decade, software tended to be monolithic. Each product was a single large piece of code, or possibly, a set of modules. Customers would purchase the software, install it on their computer and expect it to work. Microsoft Office was the epitome of this model. Then, the invention of paravirtualization and cloud computing gave rise to a new model. In the Software as a Service (SaaS) model, end users effectively rent software services. SaaS is delivered over the Internet, allowing it to be accessed from anywhere, and obviating the need to install software.

For software companies, the SaaS model brings new opportunities and new threats. On the one hand, getting new customers becomes much easier. You instantly achieve global reach and you remove risks such as software piracy. On the other hand, your customers will be fickle. There’s no significant up-front investment from them, so it’s easy for them to change supplier. And laws such as GDPR mean you can’t even retain their user data if they ask you for it. 

In this new cut-throat world, the winners are companies that respond quickest to customer needs. So, a key upshot of the SaaS model is a drive for continuous improvement of the services. This has led to a new model for development – CI/CD (Continuous Integration/Continuous Deployment). As we saw in our recent blogs on CI and CD, the aim is to test and deploy features as they are developed. This is very different from the “red letter day” release schedule that Apple adopts for iOS.

CI/CD

This blog isn’t about how to Implement CI/CD. However, it’s important to understand some of the key requirements. Firstly, you need to be able to integrate new features continuously. Typically, this is done using a system such as Jenkins or Travis CI. Then you need to be able to deploy this code into production. This requires (automated) continuous testing so that you are sure the code is reasonably robust. Finally, you need a good DevOps team who are able to monitor your production systems and react to any problems instantly. The figure below shows the CI/CD process in more detail.

As you can see, CI/CD is more cyclical than the traditional waterfall model. At each stage, the new feature can either advance or be sent back to the developers. Usually, there are three environments. Testing is used to verify new features as they are integrated. Staging is used to deploy the new features and verify they work on production-ready servers. Finally, Production is where the code seen by end users runs.

So we come to Shift Right

Companies that have made a success of continuous deployment have adopted a number of strategies. These strategies have evolved over time and are the result of much trial and error. Key strategies include Dark Launching, Canary Testing, Code Instrumentation, Production User Monitoring, and Production Testing. Collectively, these involve shifting more testing resources into production. Hence the phrase, Shift Right.

In the next blog, we will see what you need to do in order to implement Shift Right. Most of these concepts aren’t new, and many of them come from the major SaaS and IaaS providers. We will also look at the apparent tension between Shift Left and Shift Right. By the end, you will understand why you should adopt Shift Right in your business as addressed in the Functionize Manifesto.