Shift Left

Planning

Do everything possible at all levels of the organization to try to shift the testing effort upstream of the solution

Planning

Description

Whatever the name you assign to software quality practices, there are mainly four classes of testing styles for any artifact:

  1. Preventing bugs before they are introduced in the artifact
  2. Reviewing the artifact while it is being built
  3. Reviewing the artifact once it is eventually ready for delivering to Customers - both static and dynamic reviews
  4. Monitoring dynamically the artifact once it is delivered to Customer - see Shift Right
Shift Left Testing and types of testing
Shift Left Testing and types of testing

The test principle “Early testing” [ISTQB 2018] relates to testing as soon as possible, that is to say tests types A if possible, eventually B if Testers can participate in the product ideation process. The idea of “Shift Left Testing” is pulling the testing effort towards A, as much as possible, i.e. shifting the testing effort on the left side of the SDLC. However, with agile development, the product is built iteratively which means that types C and D will participate in “testing early” for the next product increment. 

Therefore early testing strategy should be thought of as continuously performing and improving testing wherever in the SDLC. Thus, the Swiss cheese model [Reason 2006] can be used to manage the appropriate quality standard to apply regarding the context [Bach 2019]:

  • existing controls may be reinforced to reduce holes in cheese slices
  • extra controls may be added if more appropriate or cheaper (Pareto’s law)
Illustration from [Moustier 2019-1]
Illustration from [Moustier 2019-1]

The Swiss cheese model highlights the necessity to combine tests that is confirmed by the table here below which provides an average percentage of defects found in type C static tests [Firesmith 2014]:

Average Percentage of Defects Found
as a Function of Static Verification Method and Defect Type [Firesmith 2014]

When combining static and dynamic, the total effectiveness would reach only 99.27%.

This figure may seem fair, though it does not take into account the financial impact behind it : between $22.2 billion and $59.5 billion annually [NIST 2002][Firesmith 2014] or even up to $113 billion knowing that only $30 billion would end world hunger [Initial State 2014].

To raise the bar regarding defect identification, we need to tackle the hidden devil in every detail through numerous testing techniques that offer different perspectives on the item we want to test as per the “Testing is context dependent” principle [ISTQB 2018], just as you would walk around a car to inspect for defects when you buy it.

Another benefit of shift left testing is that Non Functional Requirements (NFR) are taken into account very early. This is utmostly critical because NFR are among the “Architecturally Significant Requirements” (ASR) [Chen 2013], i.e. they impact drastically the way the architecture will look like.

Impact on the testing maturity

The so-called “Continuous Testing” is a combined series of activities and mindset which includes 

Every time a test is done to prevent some undesirable situations, there should be some kind of gouvernance knowledge that should guide you, beyond the simple and explicit requirements. This is what is named “Double Loop Learning” [Argyris 1977]. The more you try to anticipate, the more fuzzy those explicit requirements may be. This is why X-Teams and PanTesting should be of great help to dive even more into the Shift Left matter.

Agilitest’s standpoint on this practice

Since Agilitest is designed for Functional End-to-End testing, Agilitest is usually involved at the end of the SDLC and there is a risk that those tests would delay the product delivery or lower the flow or happen after the Sprint and deployment.

Shift left is extremely valuable when it comes to test scripts automation because it gives you the opportunity to run your tests during the Sprint. This testing strategy leads towards some agile practices at least regarding team collaboration [Subrahmanyam 2021] because testing at the end appears to be a pitfall [Firesmith 2014][Magowan 2020].


Related cards

To go further

  • [Firesmith 2014] : Donald G. Firesmith - AUG 2014 - “Common System and Software Testing Pitfalls: How to Prevent and Mitigate Them: Descriptions, Symptoms, Consequences, Causes, and Recommendations” - isbn:9780133748550
  • [Initial State 2014] : www.InitialState.com - « The Cost (and Opportunity) of Product Bugs » - 2014 - https://fr.slideshare.net/initialstate/product-bug-infographic
  • [Moustier 2019-1] : Christophe Moustier – JUN 2019 – « Le test en mode agile » - ISBN 978-2-409-01943-2
© Christophe Moustier - 2021