Testing — Shifting Left

There was a post awhile ago on LinkedIn that put an argument forward with words that I can’t quite remember. On the lines that “the shifting left approach was damaging the testing profession. Most of our testing happens after the code is written.”

A few weeks later I came across some notes that I had written from a source now unknown (reminder to always add my references to learnings in future). It stated that -

Most of the testing energy peaks after the code has been written. What shifting left was about, was to reduce that spike in energy and move it earlier on.

For me, I imagine a graph with y axis testing energy and x axis the software delivery life cycle from kick off to monitoring in production. In some places I have worked this has definitely been the case where the testing energy has peaked after the code has been written. This ended up in coaching/mentoring that you can do a lot more before then.

Exercise to plot your testing

What would be an interesting exercise is to plot all the activities you do across the x axis, maybe you could have time, instead of energy, on the y axis. This would be a great reflection piece to see what you are actually doing. It would be time consuming to figure it all out, however, a worthwhile exercise in my book. Then you could create experiments to move your time elsewhere to see if it adds more value. (I do love a good experiment!)

Shift left is not undermining the testing profession

I feel like the original LinkedIn post forgot about how important planning is and creating our test strategies. It needs thoughtful time and attention. Or creating a good set of requirements that covers all the quality attributes. You can potentially raise a lot of risks before even a line of code is written. Or during the code writing process before the code is committed to the main branch.