My shift-left testing journey

"I know these shift left meetings are new but i just wanted to say out of all the meetings i go to these add the most value to me personally, i come out of them feeling more confident and like i actually understand what's going on (for the most part) :) "

Charlotte Beever, my QA team mate

I am a fresh Product Owner (PO), responsible for overseeing each stage of the product delivery and managing the priorities. I am no newbie in the agile world. Despite this, as a PO, I've made so many anti-agile patterns in the past few months. I'll share my lessons learned in the following posts. Now, I would love to share something I think I did right. My colleague gave me just positive feedback, and I am so pumped!

We've tried to kick off SHIFT-LEFT TESTING. There are plenty of articles around how to get "lefter". Few years back, I heard an amazing speech at Scaled Agile Framework conference, where the idea to practice this, was to have PO and QA (Quality Assurance) team working very closely at early stage of defining the features / epics together. The simplicity, how obvious, yet "new", ... . It was so intense, that I promised myself, I'll immediately try it when I'll have the opportunity to. Few years later, as a PO, lucky enough to have an excellent colleagues open to experiment, we've had!

How do we do shift-left testing?

To be honest, it's no rocket science.

PO & QA create space to chat (whatever frequency necessary)PO to share the vision and idea to split into smaller deliverables/features/epics...QA to provide feedback, suggestions, remarks, questions, concerns, risks ....PO & QA discuss how each epic can be testedThe "How to test" section becomes part of each epic descriptionPO writes/adjusts acceptance criteria and splits epic to product backlog items considering information provided by QA so farProduct backlog refinements are better due to PO being better preparedPO and the whole team discuss and iterate over requirements until everyone is aligned (about vision, expectations, scenarios, split, estimation, ... )inspect, adapt, improve

As simple as it sounds, reality might be thought. But again, no rocket science!


To me, it's

expectations understanding alignment earlyidentification of unknowns earlycustomer centricitycollaborationqualityknowledge transferconfidence

Any risks?


Suppose PO will bring a massive number of features, months and years ahead, or spend time on a detailed defined epic. This, to me, smells waterfall-y. Spending an enormous amount of time on the definition of something which might not happen is discouraging. I know; I defined a few detailed epics, which were thrown out a window, misinterpreted or misunderstood vision or the team is just skilled enough not to need me writing down every single button behavior. And I only was the one wasting time. Imagine how "successful" movement to left kick-off can be when you pull the QA team into this detailed definition flow. It's such a waste!


I value QAs input a lot. I believe their constructive critical mindset incorporated into the early stages of vision definition can help with driving discussions around customer centricity and good quality. The feedback shared at the beginning of this post confirms that we are taking a good direction. Wish us luck!

If you have any experience with shift-left testing (good or bad), I'll be happy to hear all about it. Please drop me a comment on the social platform or via the Contact form.