Yesterday, we had the pleasure of listening to a brilliant session of Software Testing Live with Ben Dowen (fullsnacktester) feat. Callum Akehurst-Ryan (cakehurstryan) – The Awesome Power of Shifting Left.
Ben (who’s acting as a Product Owner) discussed the The Snack Shop and a User Story which is a simple sentence that was then hit by a myriad of questions by Callum, to the viewer’s delight. After that, a system structure has been presented which triggered even more questions (still to our delight).
Throughout the session, Callum have been reiterating about what Ben Want for the Shop to be, not How they make it. It’s also interesting when Callum talked about the practice of creating User Stories and Acceptance Criteria first before making a more detailed structure. Ben also had his realizations about this when he mentioned that sometimes, the designing of a project goes to the systems first and they just end up defining what they did instead of actually knowing what they want from the get-go.
The Shift-Left approach is generally defined as a practice of reviewing the specification or documents and making test cases early, before code or a detailed structure is made. Is it common practice or is it a case-to-case basis?
How deep of a discussion is it about a single user story when you apply the Shift-Left approach? Who do you involve in such discussions? What are the pros and cons of this kind of early testing?
And for a software that continuously evolve, how is Shift-Left Approach being utilized?
Shift left has many definitions but is usually utilised as a term to either address a current dysfunctional practice or to gain some specific benefits from earlier involvement of testers in a project.
For example many companies involve their testers day one on a project, often testing ideas spotting potential risks in the discussions regarding how a product will begin and evolve. The level of involvement may vary but there is really no need to shift left here because their starting point is left. Its generally viewed as a good practice.
What had though become common was the idea of bringing testers and only considering testing mid to late in a product or projects lifecycle. Its grey whether its a dysfunction but often it was not done with the consideration of the value of doing things earlier in the cycle. Either way the fancy name “shift left” was to counter what was viewed as a lessor practice that may have missed the opportunities of early involvement and consideration.
Its as simple as getting testers involved and the consideration of testing as early as possible, once this happens its likely you will spot even more opportunities of value from early involvement.
In real world scenario’s though I still find my early involvement very light and usually does not make sense for me to be fully allocated to a project from day one.
It rare in my view to find strong reasons for not having the early involvement but that idea of fully allocated or not at all may be part of it for some teams, if its too problematic to involve a tester for half a day a week sometimes it gets pushed back and sometimes the impact of this is fairly small.
Things that I’ve been doing over the past year or so to work towards shifting left. I imagine there’s more than this, but, these are some points I can think of right now:
One of the main things has just been getting involved throughout the lifecycle as much as possible. From the point of identifying and understanding problems, to coming up with solutions, to doing spikes into possible solutions, refinements to figure out acceptance criteria for tickets, helping to figure how something’s going to be done, to testing (if it needs to be done by me) to figuring out release plans and checking production after a release is done. My aim being to get people thinking about as much as possible to help prevent bugs from happening in the first place.
Managing risk by identifying and discussing unknowns and possible risks. I’m also a strong advocate for breaking work down into as small a piece as possible to lessen risk but also to make things flow through faster. And where need be we use feature flags to be able to release little and often.
Sharing testing with devs and anyone else who is willing and able. We discuss up front whether a ticket needs to go through a tester or if a dev is happy to do the testing. By this point we’ve already discussed risks and what needs testing so it’s not daunting. Where there’s more risk and complexity I’ll get involved either in pair testing with the dev or testing by myself. We’ve also started doing bug hunts which have uncovered really helpful things so far.
Automation is also a shared activity. We discuss as a team where things need automating. We try to avoid too much crossover between different levels of testing. E.g. if something can be covered by unit tests it doesn’t a test in cypress. I cover the end-to-end tests but even then devs will help out with approach or where things get more complicated.
Monitoring is also really helpful and the devs are alerted to abnormal behaviour which likely means someone is experiencing a problem of some kind.
Discussing quality and what it means to the team so we can identify areas to focus on.
Sorry. Just realised I didn’t actually answer your questions at the end of your post!
We discuss a story for as long as it needs it tbh. We have weekly refinement sessions where discuss multiple tickets and if we need to discuss a user story over multiple sessions then we will. We discuss it until we’re all happy we understand it and have covered off as much as we think we can think of. I do find I have to push the discussion a bit more on some tickets but not too often.
We have everyone in the team involved in these discussions, that being frontend and backend devs, product manager, design and QA. It might also prompt us to have conversations with other people around the company, depending on what problem we’re solving and who we’re solving it for.
I find the pros are that you catch bugs before they make it into the code. You work better as a team going in the same direction. Communication is better. QA is more respected.
In terms of cons, I don’t know how well formulated these thoughts are but I think maybe the main concern I’ve maybe seen so far is that it means you have to really step up and upskill in all kinds of ways. However, although this can be quite daunting and uncertain I’m really enjoying it (so that could maybe sit between pros and cons)
Potential cons are that devs might feel a bit put out by the change in ways of working but so far I think devs I’ve worked with have been mostly positive about it.
That’s totally relatable! Sometimes I veer off the tracks when I’m trying to answer a question too. But I think what you’ve shared so far makes fair sense
I figured to get to the point where the early inquisitiveness is as sharp as what was shown in this Live Testing Episode, it’s true there would have been expertise and a looot of experience too!
I wouldn’t let that be a barrier. I think curiosity and asking questions goes a long way. I think being a bit shameless about asking questions and making sure you understand what’s being discussed goes a long way. Experience and knowledge might help you along a bit faster but I just go with being a bit relentless about making sure I understand what’s going on and I often (thankfully) find that if I don’t understand there’s usually someone else on the call who doesn’t either. It just takes someone to speak up. And remembering shared understanding is one of the goals
Some time back, I wrote a paper on ShiftLeft, few glimpses from it:
How to Implement Shift Left:
Requirement Gathering: Senior testers and senior developers should participate in the requirement review and analyze requirements, design, and propose delivery estimates.
Common Test Strategy: Create a common test strategy that includes environment setup, list of dependencies, simulator creation, test data for testing, result format, and capturing logs. We should also have clarity on assignments to team members with definite timelines.
The inception of Automation : As QA will be involved from the start, additional test cases shall be developed, and regression testing is run multiple times. To get around this, automation must begin concurrently with the development phase; that is, as soon as the development team commits its code, the automation team commits its code to the test application
While advocating for shift left is a positive thing, “Shift Right testing” also exists. Its testing is done in a real-world environment and is only able to test performance or an application under excessive load when it is connected to or integrated with a large number of interfaces/clusters.
@lili
“Shift-Left is not just early testing; it is about early alignment.”
The session went on to explain that it is always better to focus on what we want before we focus on how to build it. Asking harder questions around a simple user story often brings forth real risks and value.
It cannot be just the QA team knowing the risks and acting against them; it needs to be a team mentality! When done correctly, Shift-Left seriously reduces rework, fosters clarity, and contributes to smarter delivery.
Great nuggets from Ben & Callum — an important reminder that better conversations lead to better software.
Hi! it’s me, Callum, one of the people from the session!
Firstly, thank you for the lovely comments, I’m glad to see that it’s sparked thinking with people. I love being able to share ideas and help people to see the art of the possible
What I shared in the session last week was the early shift-left questioning that relates to my context as a pretty senior tester in a more start-up engineering organisation. Your context might make your shift left testing look different and THAT’S OKAY!
Reviewing requirements to ask questions & gain understanding
Checking to see if we can write test cases from a requirements doc
Challenging asks to uncover what’s really needed
Asking for clarification to ensure a requirement can pass/fail
Hunting for missing requirements early (before we code) so they can be included
At times I feel this is a filler activity when the tester has too much time due to overallocation early in the project and someone suggests write test cases to keep them busy.
Putting a lot of effort to argue the value of getting involved early and then you find yourself doing what you regard as a very low value activity risks avoidance of getting involved early and missing out on the other valuable things.
Testability is a high value topic of early involvement and I do feel risk lists which could lead into early test charter ideas can be useful but test cases still feels like one step forward and two steps back.
The amount of unknowns early project are part of this so its not just my general view on test cases carrying too much waste and then also adding in rework waste later. It can then create the situation where shift left just creates the situation of just doing even more wasteful activities rather than re-thinking the whole testing model by the opportunities being involved early creates.
Being involved early in acceptance criteria is a bit different or other example driven development models like BDD.
I was in the situation recently and did write quite a test cases on request, 3 months later when it was ready I had forgotten I had written them and did the usual charter approach. When I did remember them and thought worth checking if I had missed anything in my usual test session it turned out I had naturally covered them all and much more with the usual approach.
That is not to say they were entirely wasteful as creating them does get you thinking more about risks and discussing those early but that byproduct was far more valuable than the test cases themselves.
Different people and teams will see more value in test cases than I but its worth flagging that risk of shifting left and just doing more wasteful things as filler to keep busy.
I feel like relating this with making art. Or an article. Or anything creative. Kind of like you make the first drafts and as time goes by the thing you are making gets better and more polished. Does that make sense?
There should also be an ask me anything on How to Question Nicely! by the end of the session you also shared about that. (That’s a whole another topic tho!)
I’d agree and say that your context and how your organisation / team works should shape how you test. It’s important that we as testers know WHAT IS POSSIBLE and why we’d use certain techniques in order to select the best approach for the context we’re in.
When’s it the best time to get involved early?
When there’s team buy in for finding risks early
When the team will change user stories and ACs based on feedback
When it’s about quality (not testing)
When there’s the psychological safety to have conversations out in the open
When the team’s defined quality (how good what they’re working on needs to be)
When you feel you have the skills to be involved in that way!
It’s worth noting that shifting left is a technique to provide clarity of what to build and shake out potential assumptions / risks early. We’re not looking to necessarily just do the testing we’d do but earlier… it’s a different thing with different outcomes
Sounds like folk had a good and inspiring time in the live session. Sounds like I also missed a thing in looking at left-shift as a way to talk about the things that a business sees as ongoing changes, but instead to see the changes as pointing to a new goal which we can better anticipate right now. Left shift of some sort has been a vital force in every org I have worked in for over a decade now. Making process changes is very unglamorous work, and hard to do without measurements of some sort or other. But I would not wait for agreement on metrics. I recently started in a new job, where there are very few metrics to guide me in the changes I need to make. And while I could spend vital hours trying to negotiate metrics, I’ve found that making changes anyway and then trying to just work out which metrics matter to stakeholders, is in itself shifting the conversation along. Crowd sourcing of change if you like.
So yeah, even if you are a solo QA, you can get other people enthused about things like making the software easier to test, or to get you involved in software design earlier. Especially when making it possible to test the code before it’s really even working can just speed up a delivery immensely.
The most thing as a tester is critical thinking at all stages of requirements, user stories, test ideas. I have seen very often that the requirements or user stories change during a project or that a project is cancelled. As a development team (incl testing) you need to adapt quickly. Perhaps Rapid Software testing (from James Bach and Michael Bolton) might be a better approach.
Some areas like Medical industry requires Shift-left approach due to regularly requirements. Don’t follow a method directly but see and discuss with your team for a good approach. Be careful to use chat GTP or any other AI tools. critical thinking is key, that’s what you are paid to do and contribute to quality
On my phone (in a pub) so apologies if I’m clunky in my reply.
A key thing that I would always highlight is that “testing” isn’t just limited to verification of implementation. We should be testing ideas, considering and raising testing earlier. Shift left, to me, is about finding issues as early as possible.
Don’t wait until a feature is done to find out it doesn’t work, test each story as they are implemented.
Don’t wait until a user story is implemented before you explore edge cases. Consider them before implementing.
Don’t wait until a story is in progress to find out it is a flawed idea. Test the requirements through questions or data analysis.
In terms for who to involve… Who is involved in the delivery of your software? Involved them.
Personally I think refinement and planning of work is best when you have product, implementation and quality focused minds in the same room.
Instead of being involved at the testing stage, being involved at an early stage, such as a product requirement meeting, is an approach that shifts left from my perspective.
The benefit of shift left is that there are many gaps or mismatches in the requirement which can be identified at an early stage, hence saving cost and time however, it comes at its own cost. Sometimes the meeting drags because of such a discussion, and hence consumes everyone’s time.
Also, it is possible that the more the discussion, there is more the possibility that the client/customer may identify a new requirement, which could add more stress for the whole team.
It is a clear benefit that everyone is aligned as to what the details are and what they want with the product at an early stage. When it comes to these meetings maybe being draggy — is there a way to combat that? Some boundaries or clear agenda?
With products having ever-changing, ever updating requirements being more common, is there a way to explore in the early stage without extending too much that the effort gets wasted? Or that would be just how it is?
There should also be an ask me anything on How to Question Nicely! 