Shifting left — what’s that all about?

Full disclaimer:

This blog post consists of a string of thoughts that have been inspired by things I have read or heard. Therefore it might look like I do nothing here except name-dropping, but my intention is to hopefully clarify where my thoughts come from and why.

Some time ago, I watched a recording of a panel that discussed the following subject:

“What is good testing in 2022?”

Google “What is good testing in 2022 TechWell” and you’ll find the recording. For some reason, Medium doesn’t allow me to post the link here directly…

One of the things that were discussed was the expression “shift left”, what that could mean and what sort of impact “shifting left” could have on testing (that discussion starts 53 min into the recording).

When I google “What does shift left mean”, this is the first explanation I get:

“Shift-left is the practice of moving testing, quality, and performance evaluation early in the software development process, thus the process of shifting to the “left” side of the DevOps lifecycle.”

A few days after I listened to the recording, I saw this tweet from Vernon Richards:

So a thought that came to me when I read that was that one thing “shift left” could mean is that we actively choose to closely observe and identify risks in the project that could potentially threaten the value or the successful completion of the product. By that, I mean that we critically look at how we work together and how well our process and way of communicating serve our mission of building a valuable product together.

If that thought has some merit, one possible explanation of what “shift left” means could be:

“Shift-left is the practice of examining, evaluating and improving the work process as early and frequently as possible since the quality of our product will most likely in many aspects be a reflection of the quality of how well we work together.”

As I thought about this, another tweet caught my attention, this time from John Cutler:

That list reminded me of something… It reminded me of different lists of testing heuristics or sources of test ideas that I have come across. Here is one example from Rikard Edgren’s book “The little black book on test design:

So could it be that “shift-left” might mean that you try to use another set of heuristics with the goal of finding bugs in the work process and in the ideas we have about the product we plan to build?

Finding a bug in a product gives you a learning opportunity. It could be reasonable to ask what caused the bug and how similar bugs can be prevented in the future. Perhaps you realize that you need to implement more automated checks, or expand your risk matrix, or spread knowledge about the product, or…change something about how you as a team develop the product.

Two things came to my mind. First this quote:

”No matter how it looks at first, it’s always a people problem.”

– Gerald Weinberg

And then this thread about change:

“Shift left” maybe is based on the hypothesis that if one starts to investigate bugs found in a product, the further one traces the origin of the bugs, the chances are that one will eventually find the origin somewhere to the left in the development process?

Is it a part of the role of the tester to try to identify and influence potential flaws in how we work together? I don’t know. But my friend Pradeep Soundararajan seems to think so:

“Mindset of Testers need to be

a) Prevent bugs
b) Escalate early and influence people”

I think I can understand why some testers over time start to take interest in the quality of the collaboration and communication within the team and within the organization.

Perhaps everybody should care about that?

I´d like to end with some words from Nivia Henry:

Davids original post can be found here