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:

• Failure in delivering software 
• Poor quality
• High cost
• High rework
• Unhappy and frustrated customer
• Unhappy and frustrated team

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?

• Engage early: Testers need to engage early in the system right from project initiation to start the integration with the rest of the project stakeholders and to provide useful inputs and collect them at every stage of the software development life cycle.

• Work with the Business and Operations teams: Testers should work with the Business and Operations teams and gain clarity on the software and provide a clear view on demand and help in planning efficiently on resource needs, training needs and testing tool requirements.
• Test leadership: Tester should work with the rest of the team to provide great test leadership and guidance to the team thereby keeping the long-term product vision in mind rather than just taking the responsibility of testing activities.
• Requirements: Requirements are the key to the success of any product and well-defined requirements define the success of the project. During the requirements planning phase, testers need to review and analyze the requirements for any better clarity, completeness, testability, acceptance criteria definition etc. Also testers should identify the missing requirements, understand the dependencies and implementation strategies. 
• Design review meetings: Testers should attend Design review meetings regularly to understand the product design and architecture and identify the design flows, suggest alternate design options, identify the possible defects, and create test cases accordingly to the designs.
• Static  testing – reviews: Testers need to carry out Static testing – reviews to provide feedback on key project documents so that defects are prevented in the early stages of software development life cycle.
• Strong and robust test scenarios: Testers should design strong and robust test scenarios so that only a few defects are identified during testing and major defects are prevented while entering into the testing phase.
• Test early as possible: Testers should test as early as possible, be it on a standalone or local system, so that defect does not get into later stages.

Benefits

• Reduce costs: In a traditional software development life cycle, testing is performed in the late stages product development cycle. As mentioned before, the cost and implications involved in defect fixing would multiply based on the time when it was discovered. In Shift Left, testing is considered an essential part of each phase of development. Testing is performed on every build, and defects are caught and fixed at an early stage. When code size becomes increased, fixing simple issues could also take additional time and may cause some side effects. Shift Left testing strategy can reduce the overall costs of development, testing and fixing since defects are founded in earlier phases.
• Early defect detection: In the Shift Left method all stakeholders on project work together. Developers can work on the development of unit tests, as well as system tests. Automation is a main part of Shift Left testing. With automation scripts team can perform testing a few times each day. Test results go back to the product development channel which helps in improving the code quality. Overall code quality would be better with early and often code quality checks, which result in stable products delivered to the customer. 
• Effective defect resolving: As mentioned above Shift Left testing helps to bring more coordination between developers and testers. Testing begins in the early stage of the software development life cycle which opens up the software for review and correction directly from the beginning. And this is one of the main benefits of this method, which recognises and fixes defects in time.
• Improved test coverage: Because of that tests are executed directly in the development process, software can be evaluated for all their features. Software is tested for each functionality also with product performance. Improved test coverage helps in assuring the quality of the software.
• Effective use of time and resources: When defect is detected and fixed in time it helps to deliver software on predefined time and allows effective use of resources. When testers work with developers, the overall process helps in making the application stronger by effectively using the skills and delivering results. This further results in cost-effectiveness, which is necessary for sustaining profitability in the commercial area. 

Best practices

• Design testing plan: Before starting a software development life cycle it is necessary to define and plan for each part of the life cycle. By doing this all stakeholders on the project will be able to understand all tasks, objectives and expectations of the project. The testing part of the software development life cycle should also be defined and designed for all the requirements, specifications and design testing plan.
• Integrate all stakeholders with testing: Integration of all stakeholders (development, operation, project management) with testing is an important step before beginning of testing. With this integration it will be easier to define at which stages testing should occur. This will help to recognise and estimate time to complete the testing cycle.

• Define quality standards: Quality standards should be defined to help to recognize  whether the development process follows with QA and identify any deviations from the required outcome. This will lead to using corrective actions at the individual and also on all stages, which will be beneficial to the project.

• Include testers in coding: Including testers in coding knowledge can help testers to understand code with a more in-depth analysis of the defects. Coding knowledge can help to detect and identify defects and suggest solutions to resolve defects.

• Include test automation: To be able to get full benefit of implementing Shift Left model automation test should be included. With automation tests, developers and testers will be able to automate the whole build process and to test processes over all phases of the software development life cycle.

• Continuous feedback: Continuous feedback should be defined so that testers can constantly give feedback to developers during and after all phases of software development life cycle.  Then it becomes easy to report defects and accomplish required quality.
• Coding with a testability mindset: When thinking about Shift Left, we should think about developers starting the development process with a testability mind. This means that every developer should be responsible for ensuring quality on the written code which will help in creating testing systems. With this, creation and maintenance testing systems and automation scripts will be easier.
• Track everything: Use measurements and set pass/fail criteria. Continuous testing is about immediately identifying if things are working or not, so make sure you can set that up quickly. Break work down into smaller increments that are easier to test after coding and design. This makes it easier to automate the tests, and it also makes things much more readily deployable.
• System to display results: Do dive deeply into results, because that’s a way to know if code is working and where the gaps are. Define KPI’s and recognition criteria and make them quantifiable. Create dashboards to track the KPIs, including a baseline and subsequent changes.

Challenges

• Planning: Shift Left testing can be difficult to incorporate without an effective plan in place before beginning.
• Project management: Properly prepare and train project managers to incorporate Shift Left testing into their processes.
• Quality control: Maintaining excellent quality levels during the training and transition phase.
• Developers: Developers can be resistant to testing and should be prepared to add testability to their skillset.
• Silos: Reduce the silos in organization to provide swift feedback to fix problems faster and more efficiently.
• Audits: If an organization does not actively participate in regular code audits, make sure this is set up to ensure the new testing procedure is working as intended.

Examples

• Pair with developers: More collaboration and discussing requirements and test scenarios with a team including developers and product owners so that unknown risks can be discovered early as possible. Both developers and testers need to have the same understanding of the requirements.
• API first approach: In all applications API’s are developed first. Team should plan API testing, so that issues can be identified early in the cycle rather than just testing from the UI.
• Plan Non-functional testing (Performance, Security, etc..): Performing Non-functional tests early in the cycle so that risk can be minimized.
• Automate test case execution: Integrate automation scripts with any build automation tools so that automation scripts should run before new code deployment. It will help ensure that new code changes are safe or not.
• Automate Unit tests, Integration tests, API tests: These tests run faster and help in identifying the defect early in the cycle.

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