Shift Left testing – mindset and culture shift

Programming left shift testing softhouse

Traditional testing model relies on a sequential software development process that follows pre-defined phases, for example Plan & Design, Develop & Build, Test, Deploy & Release and Maintenance. In this model, planning (requirement) is kept on the left side and delivery and testing on the right side. Least attention to quality is given in early Plan & Design phases and the most attention to quality is given in late phases in the software development life cycle. Most defects are not identified till late in the software development life cycle where defects are expensive to fix. 

This result in:

Shift Left testing model is a practice or model to find and identify defects early in software development life cycle. The main focus is to improve software quality by moving testing early as much as possible. Shift Left testing is not a new model, it has always been around, and it is all about involving testers much earlier in the software development life cycle, which allows them to understand the requirements, software design, architecture, coding and its functionality, ask questions to customers, business analysts, developers, seek clarifications, and provide feedback wherever is possible to support the team.

This involvement and understanding will lead the testers to gain complete knowledge about the product, think through various scenarios, design real-time scenarios based on the software behavior which would help the team in identifying the defects even before coding is done.  The goal is also to automate as much application, maximize our test coverage and perform testing early in the software development life cycle. Automation scripts are running on each build, and if they fail, then the build should fail also. The applications are constantly tested during each phase, not only on the last phase before delivering. Testing each feature with each build guarantees  a required and satisfied level of quality in the application that will help to ensure an effective production release.

Bug life cycle – Traditional model

Defects are introduced at each phase of software development life cycle. The majority of defects come during the development (coding) phase, which is to be expected and there are a lot of reasons for that: misunderstanding the requirements, not proper design, time pressure, less communication between all stakeholders on the project, changing requirements.  Defects are also introduced into the application when it is a time to put all pieces together. But this is not surprising, because defects are usually founded when testing begins and it can also be difficult to detect defects without a proper testing infrastructure. The general case is that the defects are mostly introduced during coding, but they are almost never found at that phase. Defects are usually detected in the late phase of software development life cycle, before product release or in the worst scenario in production. 

From the other side, how does this co-relate with costs and difference in cost to fix defects at each phase of the software development life cycle? When defects are introduced during the coding phase and founded in late phases, progression of costs dramatically increases. For example if defects are found in the system testing phase the cost is 40x bigger than finding it during coding, or 10x more costly than finding that same defects during unit testing.  And it just gets so expensive to fix defects when numbers of detected defects are many in deployment and release phase. There are several reasons why costs are growing: time and effort to track down the problem, the complex defect is more complex and difficult to figure out which part of it is the real troublemaker and more complex and expensive to fix. Reproducing defects in different environments is also the reason why costs are rapidly growing. Another reason is the impact of the change that is needed to fix a defect. If it is a simple defect, it does not matter so much. But if it is in many places, or if the wrong framework is used, or if code is not scalable enough for the expected load, there are a lot of other reasons why costs are growing.

Bug life cycle – Shift Left model

Doing some early practices in the software development life cycle, such as static code analysis and unit testing, helps to identify and prevent defects earlier in the process. It is important to remember that the goal is not to find defects, but it is to reduce the number of defects, especially those that make it into the release. Creating less defects in the earlier phase is more valuable than finding more defects and it is a lot cheaper. Coding standards are also the key to reducing the number of defects in addition to finding them earlier and to support and get the most value out of the Shift Left model. Coding standards help to avoid bad, dangerous, insecure code and to use them apply static code analysis.

By implementing some of these practices earlier in the software development process “defects found” bars grow larger on the cheap side and become smaller on the expensive side, which gives a pretty significant cost reduction which is shown on the graph below. 

Introduced defects are decreased at the earlier phases by implementing some of these practices and also with including testers in early phases of the software development life cycle. Shifting left should be moved left as much as possible and this is a phase where defects are introduced, so let’s start looking for them while development is still in progress. This is where the benefits of shifting left become visible, finding defects even farther to the left where defects are cheapest to fix. Also involving testers in all important and critical phases of the software development life cycle is the most important part of the Shift left model. It enables the testers to change their focus from defect detection to defect prevention. With increased responsibility to tester, the tester just does not focus on testing the software to identify the defect, but they also work with the development team right from the initial stages to plan and build a robust and effective testing strategy by focusing on the long-term vision of the product, rather than just taking the responsibility of the testing work. 

How Shift Left testing works?

Shift Left is a practice in the software development life cycle in which team focus is on quality, on problem prevention instead of detection, and the early start of testing as much as possible. The Shift Left model can be related to “Test early, test often” principles. The main idea is to improve and increase software quality, to have happy clients, decrease long test cycles, decrease costs, minimize and reduce possibility of unwanted surprises at the end of the software development life cycle and in production in the worst scenario. 

To be able to start with the Shift Left model the Continuous Testing and the Continuous Deployment part should be included in the model as well. Continuous Testing is the process of executing automated tests as part of the software delivery pipeline in order to obtain feedback on the business risks associated with a software release candidate as rapidly as possible. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment triggered tests as well as more traditional developer/tester triggered tests. Continuous deployment automates the deployment and provisioning of new builds, allowing Continuous testing to happen rapidly and efficiently.  

The first method to start with “shifting left” is that the Operation team works side by side with the Development team in creating testing and deployment processes.  Defects detected in the production stage usually are not detected earlier in the software development life cycle and these defects can be related directly to differences in deployment and development procedures. These procedures in the development environment can be very different from procedures in production and should be built as standard deployment procedures for all environments. The deployment process is then practiced hundreds of times in test environments before reaching production environments.  Creating all environments in the pipeline to look like a production environment is the next step to reduce or minimize defect rate. Production environments usually are much larger and detailed than needed by development. But by using cloud and similar tools, they can be much closer.

How testers should work in Shift Left testing?

Benefits

Best practices

Challenges

Examples

Conclusion

The testing processes that have proven effective over many decades can be utilized to dramatically improve quality while saving time and money. When shifting left by leveraging modern software testing technologies, software that is safe, reliable, and secure can be achievable.

By shifting testing left, the cost of testing can be reduced by finding defects earlier, when it is cheaper, while also reducing the number of defects you put into the code in the first place. Every team member holds an equal responsibility for producing high quality software. Shift Left testing is not only a process it is a mindset and culture shift.

Author Admir Satara