I have heard this topic discussed recently and I watched a team unsuccessfully implement the concept. Just wondering what are your thoughts or experiences with this concept?
What It Means to “Shift Left” in Software Testing | SmartBear
1 Like
Well, the term “shift-left” can be a little buzzwordy, but the way I see it is mostly about early testing, or doing testing as early as possible. My personal experience is doing this approach through BDD, by testing the requirements before the code is written.
I think it’s difficult to pull off without heavy collaboration in the team, usually, it starts with a three amigos session, where a product owner, tester, and a developer go through the requirements together (usually in the form of user stories) questions the requirements, looks for ambiguities, inconsistencies, define some starting test ideas and so on.
It can be a good thing if everyone involved is invited to it, but it does take time to get used to it and while the initial investment seems high, the long-term benefits are pretty much worth it - I have to really try hard to find any significant bug in feature that has gone through all of that.
1 Like
fail early, fail often
that’s another alias for me to shift-left. Basically do things as early in cycle as possible in order to shorten cycle times. For QA, the biggest step to the left we can take is to attend a requirements gathering meeting. A low quality bar set for requirements gathering, or long out of date requirements and process/diligence means that dangerous requirements can be left in a spec until a point when changing them becomes expensive.
Hi @rominanz ,
Marcus Merrell did a good Ask Me Anything on this topic. 
Plus, is the following discussion on your radar?
Oh and I’ve literally just spotted this panel discussion:
After reading this article:
3 Likes
@scottkenyon did a video on this about (and I’m sure he will correct me if I mess it up) shifting left or right are buzz words and it is about shifting in.
When we all come together as a team to work on the problem and everyone contributes the higher the likelihood of success.
For me it means being involved early and asking questions to remove ambiguity, to challenge assumptions and look for ways of adding value and improving the quality of the product.
2 Likes
It’s a good concept but it’s not a new concept. It’s essentially a reformulation of fail fast which has been around forever.
As @mirza points out one of the best ways of applying it is to have a process for testing requirements before writing a line of code (BDD being one way you can do that).
The most successful company I ever worked at once tested a new feature that sent emails to the customers by getting somebody in the Phillipines to do everything manually first before swapping them out with an automated back end - just to confirm customers were actually going to use this new feature. That was shift left taken to a new extreme I’d never seen before.
More usually I apply shift left by seeing a CI pipeline fail after 20 minutes and thinking “how could I have made it fail quicker?”. Or manual QA finds a bug and I think “how can the CI pipeline catch that type of problem in future?”
For me it simply means ‘start early’ - myself or team members be there at the very start of the project. If we’re invited too late to the party, then we’re missing out on context / takes us longer to get up to speed.
Questions I like to ask at the start is why we’re doing a project and who for.
One project I’ve been working on has been a discovery phase. Even though we haven’t tested the product per se, we have questions project ideas/temporary solutions and so on, which the overall team have found valuable.
2 Likes