Introduction
Shift-left is a testing approach that emphasises testing early and often in the Software Development Life Cycle to catch defects and vulnerabilities as early as possible. Whilst this concept is not new, there are some emerging choices that engineering leaders can analyse and decide upon.
This is especially true for the cloud migration journey. Cloud migration is moving a company's digital assets, services, databases, IT resources, and applications partially or wholly into the cloud.
This whitepaper provides a straightforward approach to answer the critical questions on what activities form Shift-left testing, which to apply, and how to decide what resources may be required when adopting automation of testing.
Its primary position is to advocate for Shift-left, written in the context of cloud migration, as this is where we see an opportunity to effect change.
In this whitepaper, we will look at
What do we mean by shifting left?
Whether you are an engineer at the coal face, a product owner, or you are in a delivery role, you will be acutely aware of the need for testing software against requirements. In addition, you may already have a testing strategy for functional and non-functional tests operating at all levels of the testing pyramid (and in the right proportions).
The crucial part of this is when you do your testing.
Shift-left is a testing approach that emphasises testing early and often in the Software Development Life Cycle to catch defects and vulnerabilities as early as possible. Doing so improves the pace of delivery whilst keeping software stable by achieving good quality in engineering.
This approach contrasts with traditional methods, treating testing as a separate phase (often after completing the code) which can lead to delays and quality issues as defects in both code and requirements are discovered much later in the lifecycle.
By shifting the testing stage "left" in the Software Development Life Cycle, testing starts in the planning stage, where teams can identify and fix issues before they become more costly and time-consuming.
What shifting left means in real terms is:
Developers own the outcome: Software engineers take accountability for their code, which starts with ensuring good test case coverage
Quality is planned for all stages of the Testing Pyramid: Automated testing strategies consider covering Unit, Component, Integration, and End to End tests.
Implementing Test-Driven Development (TDD): Write failing automated tests before you write any code – a fundamental building block of TDD, and written about extensively in "Test Driven Developement: By Example" by Kent Beck.
Adopting Analysis Tools: Secondary tools beyond the IDE provide coding quality and coverage feedback.
Cohesion and Reusability through Frameworks: Prioritising the development of reusable standard components with high-quality levels built in.
Leveraging continuous integration and continuous delivery (CI/CD) pipelines: By automating integration and deployment, teams can catch issues earlier in the development process and reduce the time between identifying and fixing a problem.
Cloud: Knowing your Cirrus from your Stratus
Cloud computing involves hosting and deploying applications and services over the Internet rather than on physical servers or devices, offering numerous benefits, including:
Scalability: Application resources can scale up or down as needed, based on demand
Flexibility: Developers can quickly provision and deploy resources without manual hardware provisioning
Cost-efficiency: Businesses can save costs, as organisations only pay for the resources they use
Typically cloud computing is divided into three categories:
Infrastructure as a Service (IaaS): This involves providing virtualised computing resources over the Internet, including servers, storage, and networking. You must still manage the Operating System, runtime environment and any middleware
Platform as a Service (PaaS): This involves providing a platform for building, testing, and deploying applications, including tools and services for development and deployment. You must still manage the application and data
Software as a Service (SaaS): This involves providing access to software applications over the Internet without needing local installation or maintenance. You're not developing any code; you are just using the software
Shifting Left into the Cloud
Migrating applications to the cloud will likely require changes to your application's core code, be it simply updating libraries and recompiling or making holistic changes to take advantage of serverless services and capabilities.
Opening your IDE and inspecting that code resembles a mechanic lifting the hood of a car to work on its engine and make improvements. Whilst the hood is open, you might as well check the oil, fill the washer reservoir and inspect the timing belt to see all is well. Maybe you want to upgrade your turbocharger so you can go faster, and why not? The hood is open!
Like our mechanic working on the car, migrating to the cloud offers an opportunity to introduce better ways of working and improving the application – because whilst the hood is up, you are already in the mindset for change.
Shifting left during a migration provides a huge opportunity to add long-term value
Cloud migrations are not just about saving money; with modern deployment techniques such as automation of Infrastructure As Code (IAC), you can become more agile in your delivery, which means less time from concept to production. And faster delivery allows Engineers more time for innovation (because who doesn't love a bit of Greenfield development?!)
But you cannot just go fast – you must go safely.
I've seen Engineering teams shifting left and Cloud teams migrating apps as separate initiatives, with little consideration for their interdependence. But these are highly complementary – running automated tests as part of your continuous integration and deployment to cloud resources is at the heart of the practice.
If you are migrating legacy applications to the cloud, you must ensure you can do so safely. Regardless of whether you lift and shift or completely reengineer your applications, you must ensure that developers take accountability for quality, compliance and security through good levels of testing.
If rehosting takes time, refactoring takes even longer. Simply shifting left isn't going to speed up that migration either, making it hard to justify from a Business perspective: and this is the crux of the matter.
We must understand when and how far to shift left and under what circumstances this would be appropriate. We can introduce levers to help you decide how fast you go to the cloud and how far left to shift.
We must also acknowledge that shifting too far to the left could slow a Cloud migration down. But, conversely, not moving the needle far enough left prevents adopting an agile stance and loses out on the benefits associated with shifting left. It also accumulates an ugly amount of technical debt that may eventually consign your applications to their ultimate demise.
Introducing our Levers
We will use three levers to help us consider our shift-left strategy.
Our first lever is where we consider our Route To The Cloud, which may depend on factors such as the complexity of the application, budget, business requirements and appetite for destroying existing code bases and legacy infrastructure. Here are the common routes:
Two other considerations that may also be relevant to your organisation:
Shifting left is not a single activity; we can apply varying levels of shift left related to testing automation. So our third and final lever will be the Level of Automation. It is worth noting these levels are not prescriptive; you can change them to suit your needs. What is important to note is that the levels scale, meaning the implementation difficulty increases at each step, and so does the implementation time.
Knowledge and skills gaps must be in consideration here. Therefore, one would recommend a good gap analysis to help you understand the areas where you are strong or weak and help define your desired future state. In turn, that analysis will drive any training areas required to bring your teams to the level they need to be.
You will be taking a three-step sequential approach:
Let's translate that into our Decision Matrix:
When we discussed the gap analysis required to ensure you reach your desired outcomes, you may already have started thinking about what type of books to read1 and training courses to enrol your team on. But there's a vital distinction between upskilling and adding skills to your teams.
Training alone may not allow you to achieve the desired velocity: High-flying teams perform because of the hybrid nature of the availability of expertise – the right people can play pivotal roles and make a difference in your capacity.
In this instance, recommendations on who would make a difference to your Release Train are crucial to the construction of the team. Deploying these key roles are vital for success.
Therefore we can extend our model to include recommended roles for the varying levels of shift-left.
Of course, these roles are part of the broader Engineering team, which may be considering investing in a multiteam, multi-application migration. At scale, an enterprise organisation with many teams and applications may benefit from establishing two key functions:
Together, these teams can facilitate a command and control approach to manage the program with solid governance, decision-making processes, and reporting structures.
know there's a lot to take in here, so I'd like to summarise my approach:
Coforge has extensive experience helping companies shift left into the cloud: Let's engage and see how we can help you and your business.