Notes on Shift Left in Testing and Software Development

TLDR; Notes on Shift Left, where I try to explain why I don’t use the term and what I use instead. Evolve, Grow and Improve rather than Shift and Move

For some reason I’ve had a few emails and linkedin questions asking me what I think about “Shift Left”. I thought I’d put out a public answer.

I’ll start with - I do not use the term “Shift Left” because:

It seems like “consultant speak” and, while I’m a consultant, I try to speak clearly
It obscures, rather than clarifies, whatever point it is trying to make
It makes me think of ‘moving a whole thing’ rather than improving the System

Instead I think of supporting the growth and evolution of a System over its lifetime and I don’t need “Shift Left” to do that.

What might “Shift Left” mean?

I thought about what “Shift Left” might mean, before searching the web to see what people say it means.

At first hearing, the words seem to be talking about the position of things. So perhaps it means moving people physically to sit more on the left. Which seems ridiculous and couldn’t possibly mean this.

But perhaps it is referring to a factory conveyor belt assembly line production system. And we want to “Shift Left” on the conveyor belt system. Assuming the belt is moving from left to right, where left is ’less produced’ and far right is ‘finished’ then it is actually referring to time, rather than physical position.

Perhaps it means “test early”?

If it does then it seems a tad overkill to say “Shift Left” rather than “Test Early”.

But… Consultant Speak.

Consultant Speak

The art of saying words that sound simple but which actually obscure your message. When you speak Consultant people pretend to understand you, so that they don’t appear ignorant. They then repeat your phrases and spread ambiguity. You are then employed as a consultant later to fix the situation caused by the implementation of the ambiguous words.

Some sample consultancy words to try out: Facilitation, Innovation, Ideation, Initiatives (see also The Office Life Business Jargon Dictionary)

“Test Early”. Surely it can’t be that simple?

A quick Web Search search later, and I’m not picking on these articles, these were simply the first in the web search (well done on your SEO skills):

Wikipedia Shift Left Testing

Apparently it does mean test earlier.

Except when it means:

Testing Early seems like a Good Thing to do

I have nothing against the notion of “Testing stuff earlier”.

I think a good Tester finds opportunities to test early
I think a good tester finds opportunities to test where other people do not

I do try to “test stuff earlier”.

And I can do that without the concept of “Shift Left”.

Shift Left implies to me that I have:

P (a ‘process’ or a ’task’ or an ‘activity’)
which is done at a point in time (x+5)
and I can apply a “Shift Left” transformation to P
such that I can now do P at an earlier point in time e.g. (x+3) or (x+4)

And that is all it implies to me.

It offers me an overly simple model of improvement, and implies an overly simplistic model of testing, that I do not see value in adopting.

I already have a very simple model of testing that supports testing early without the concept of “Shift Left” and it is a model of testing that can adapt to Waterfall, Agile, DevOps or any other System of Development that I know of.

A Simple Model Of Testing

I present to you, a simple model of testing that does not require “Shift Left”:

This simple model of testing has Testing as “a process of building a model of the system under test and evaluating the system under test in terms of the model”.

Evaluate seems a bit “Consultancy Speak”. Feel free to use ‘compare’ if you want to.

Evaluating involves comparing the model of the system to find out:

what does it do that matches the model,
is not present in the model,
is in addition to the model.

I could model this as:

“==” - matches
- demonstrate that functionality (at a given time, with given data) repeatably provides the same answer at the level of observation adopted
- I also include “!=” in “==” because it is a boolean operator
  - something that doesn’t behave repeatably, something that doesn’t behave at all, something that behaves differently
“-” - is not present
- behaviour missing from the system that I expected, this might be a “bug” or it might mean my model needs to change etc.
“+” - is in addition too
- behaviour in the system that I didn’t expect that my model did not predict. This might be a “bug”, or a failure in communication where I didn’t know about certain functionality, or a failure in my building of the model where I neglected to incorporate this behaviour, etc.

I can change the level of observation and that changes my testing:

exclusively at the GUI
include the database
observe the file system
observe the HTTP traffic
etc.

Remember this is a simple model that may not capture all nuances associated with testing a system.

Where does time fit in?

To incorporate ’time’ in terms of “Shift Left”.

Depending on when, in the System of Development, I build the model and evaluate the System Under Test against the model, I will be able to evaluate for different properties and behaviours.

e.g. I can’t evaluate the GUI until the GUI is written, but I can evaluate the ‘design’ for the GUI or the ‘wireframes’ to see how it supports the expected behaviour.

Shift Implies Move

Shift Left implies to me that I “Test the GUI” earlier. Or I move the “Performance Testing” earlier. And this doesnt’ work for me because we’ve ‘moved’ the Performance Testing therefore we only conduct perfomance testing earlier and do not do any later. ‘Shift’ suggests a ‘move’ operation to me.

Here’s a diagram of what I mean:

We do Performance Testing
We want to “Shift Left”
We shift left

Now we do performance testing earlier. We have Shifted Left.

But:

Now we don’t do any Performance Testing later
Perhaps it was important to conduct Performance Testing later on the production environment to make sure that our load balancers work?
Perhaps the Performance Testing that we now do early is different from the Testing we did later and now targets different risks.
Perhaps we needed to do the early performance testing and perhaps there is still value inthe later Performance Testing.

The wording of “Shift Left” doesn’t cover these nuances. Which doesn’t mean that practitioners of “Shift Left” do not consider those nuances, but I have seen teams implement “Shift” as a ‘move’ rather than a nuanced ‘spread and adapt’ operation.

Shift Implies No Change to the System of Development

“Shift Left” concentrates on the Testing and seems to assume that we can do that without changing the System of Development.

When I create Test Approaches I concentrate on the System Of Development and depending on the System of Development I test in different ways.

In the simple model, I test when there are opportunities to test that add value either to:

the construction and maintenance of the model
communicating the results of evaluating the model to the System Under Test

If we can “Shift Left” regardless of our approach to developing the system then we have not implemented an effective Software Testing Strategy. i.e. if you can perform exactly the same “Test The GUI” task earlier, then why didn’t you? It could imply some organisational issues.

If we change our System of Development and do not change the approach to testing then, frankly, we are not conducting testing effectively.

Effective testing will take advantage of new opportunities to test differently.

If we start incrementally building the system in smaller chunks then we can take advantage of this to test in shorter bursts earlier rather than a long cycle of testing at the end.

If we introduce automated build processes then we can take advantage of this to automate assertions that are simple and time consuming during the build process, and cut down on the available time for exploration

Think Evolution and Growth instead of Linear Transformation

I worry that Shift Left presupposes a Linear Transformation model e.g.:

A conveyor belt factory assembly line
Throw it over the wall to the ’next discipline’
A focus on the ‘roles’ in the team, rather than the System of Development
A focus on the ‘process’ rather then the System Under Development

We build Systems that evolve and grow.

An Arborist is a person who looks after individual trees and plants. We wouldn’t ask an Arborist to “Shift Left” and prune early. An Arborist looks after a tree as it grows. The tree changes and ages over time. The Arborist responds to the needs of the tree and the risks facing the tree, over time. The Arborist does whatever is appropriate to help the tree grow and shape within the constraints and possibilities of its environment and the needs of that environment. The tree doesn’t move. The Arborist works around and within it over time.

When we build Systems. We don’t “Shift Left”. We craft a System of Development (which includes Testing) to meet the needs of the System we are building, to respond to Risks that we identify and the issues that we find. The Systems grow and evolve. We need to be good enough to identify improvements we can make and take advantage of opportunities to Test.

I believe that the notion of “Shift Left” is not required if we change our model of System Development.

“Shift Left” does not fit well into my Model of System Development.

You can find a supporting video at https://www.youtube.com/watch?v=AaMp5skiwqA