Shift Left Testing - 101

          Shift left testing is not a latest buzzword; supporters of agile practices have already suggested that testing early and often should be the regular practice. However, what is new is the usage of shift left practice in all kinds of software lifecycles. In other words, shift left testing can be applied to all kinds of SDLC models or methodologies whether it is V lifecycle or waterfall lifecycle, agile lifecycle or model-based lifecycle.

Shift left Testing -What it is

          Shift left is a holistic approach to testing and development. It is a practice that focuses on defect detection in initial stages whether it is requirement phase or design phase. Introducing shift left in a company reflects the top management’s philosophy of prediction and prevention of defects as early as possible so as to avoid the costly fixes. This requires a change in the mindset of everyone involved in the development and implementation phase. The entire focus should be on producing the high quality product right from the requirement phase. To achieve this goal, it is important to write “The Best” business requirement which is correct, clear, and complete.

          Shift left strategy is not only about doing functional testing and user acceptance testing in early stages, but also about bringing business users, user acceptance testers (who would do beta testing) from the beginning so that they can help finding the defects from requirement phase itself. Apart from moving functional, integration and nonfunctional testing to the left, is also important in catching early defects and improving the overall quality. Organizations should focus on finding defects during each review phase and improve implementation and product quality. Business and development SDLC phase owners should strive for excellence and start thinking of catching the errors or faults of their work items. In order to achieve this mission, business team should own each phase of SDLC.  In other words, shift left philosophy is all about doing things right the very first time or finding defects as soon as they arise.

Shift left Testing - What it is not

          Shift left is neither a tool nor a technology; it is a practice that requires shift in the mindset and change in processes within organizations. Shift left is commonly confused with DevOps. While Devops emphasizes on the collaboration between development, testing and other IT operations for faster delivery, shift left approach focuses on introducing the testing function early in the business processes and overall SDLC for the purpose of quality improvement.  Devops is not just a process change it requires a change in the entire IT organization and different IT operations. On the other hand, shift left is a process change which focusses on running testing in parallel with development. Shift left is also not a test-driven development or TDD, which is an approach where tests are written before the code.

Why Shift Left

          Waterfall methodology has emphasized too much on development component whereas the testing component is not well-defined (Perry & Rice, 1997). On a typical project timeline, software testing comes much later in the picture after software is build.  Oftentimes, software testing begins before the release and entire focus and pressure is on the testing team. At this juncture, it is difficult to test every aspect of the product, not to forget the time crunch and deadline. As a result, either a project gets delayed or quality of the product suffers due to the time crunch or both. Project delays are the common scenario in many companies increasing the cost of the entire project.

Shift left is an approach that can prevent cost overruns and project delays. The ultimate goal of applying this strategy is to predict and prevent defects early on in the development phase. Any defect that is detected later is more expensive than if it is detected in the early phase. The whole idea is to begin testing as early as possible and moves to the left on the project timeline. Ideally, get the testers involved in the project as early as requirements phase. However, how much to shift depends on the readiness of the company as well as testing and development teams.

Shift Left saves time and cost

          In an ideal world, prevention is better than cure. However, in SDLC, defects are neither prevented nor found and fixed as they arise. Therefore, many productive hours are spent in reworking after the defects are found and fixed. Moreover, it takes more time to identify the defects at a later stage. According to Beck & Andres (2004), “Defects are expensive, but eliminating defects is also expensive. However, most defects end up costing more than it would have cost to prevent them.”

          Therefore, the best approach is to find and fix the defects as early as they arise. While many experts would argue that it takes a lot of time in implementing shift left, in the long run shift left saves time. While defects are expensive, but finding those defects as early as they arise can save cost. In a normal SDLC, testers are not involved in initial planning, which increases the chances of defects.   

Shift left improves the Quality and provides good product as defined in scope

          While white box testing is not always possible, it is best that software testers are involved in the development phase early on to detect maximum defects and ensure the high quality software. When projects are running behind schedules, testing time is cut short in order to meet the stringent deadlines. Reducing the amount of test time, does not leave enough scope for finding bugs regardless of the competence and capabilities of a tester. As a result, the software is full of defects and the blame is passed on to the testers. Therefore, bringing testers early into the game can improve quality of the software.

 To sum up, shift left testing is advantageous in the long run, but it is not a panacea to all your software testing problems.

References

Beck, K. & Andres, C., 2004. Extreme Programming Explained: Embrace Change. 2nd ed. s.l.:Addison-Wesley.

Perry, W. E. & Rice, R. W., 1997. Surviving the Top Ten challenges of Software Testing. s.l.:Dorset House.