How did your organization implement shift left testing?

🙋 Questions
1

Curious for those who have implemented or are implementing shift left testing at the organization level.

How did your organization do it? Did your org include QA in each scrum team? Or did your org have a dev only scrum team and let Devs ensure quality?

Thanks.

1 Like
2

Is that (part of) shift left?
Then I/we do Shift Left since a decade without knowing. In multiple companies.

Wherever I was, it was always clear that testers should be in the Scrum teams.:person_shrugging:

Could you give definition of Shift Left?
I see various around.

2 Likes
3

I understand “shift left” as testing as early as possibile in the development process so that any issues are found early, when it’s easiest to fix them.

I am a tester in a scrum team. Our team does 2 things:

  1. I am involved in setting up the requirements. I flag issues about them before the dev starts coding. I already write down test ideas right after the requirements are written, the devs can see those.
  2. I can start testing right after the developer has completed their pull request. That is often on the same day. In the mean time, automated regression checks are running (but they rarely discover bugs unless there is a regression)
5 Likes
4

I do most things similar to @ifs and have even access to the feature branches. I test sometimes on them. Not always in full depth, but I discuss with the developers where I should look at now and what later. They want early feedback.
Also I’m in the situation to build and run the application on my PC, which is much faster than waiting for a build at your CI server.

Also I prefer Expand Left over Shift Left. Some people really mean to drop everything useful they did so far.

4 Likes
5

Thanks for the feedback.

Shift-left testing - Wikipedia - based on Wikipedia, shift left testing is to test as early as possible.

I agree what you and @ifs mentioned are very close to what my idea of shift left testing is.

My organization has recently changed so that scrum teams are dev only and testing are done within the team.

1 Like
6

Why do I think this sounds like excluding the tester from the teams?
Just saying devs that they should test is imo a bad move. Some still need testers, but in the teams.

2 Likes
7

Unfortunately, it is exactly what it sounds like.

That’s why I am curious how other organizations are doing shift left testing.

1 Like
8

I’m sad to here. This sounds like bad approaches I have heard of, therefore I asked. Shift Left has for me a negativ connotation and so far I never thought about to label what I do as Shift Left.
Sounds more like Trash Test.

I do not say that only testers should test. Test experts can also consulate developers testing, I do this too. But therefore they need to be in the team.

So technically speaking your company hands over (parts/more of) the responsibility for testing to the developers. But I guess they are not trained?
Just moving the label, but not the skills.
What do they plan with the tester? Still being in dedicated test teams? Being layedoff?

Are people in your company calling the change Shift Left or is it mostly you?

2 Likes
9

Great question, @mtest.

A couple of things come to mind.

  1. Gus’s talk from TestBash Belfast. I happened to see it live as we were both speaking at the event. Tonnes of useful learnings and excellent energy from Gus.
  2. There is a tonne of excellent questions from the community about “Shifting Left and Shifting Right” in this Ask Me Anything with @mmerrell. Questions like " What kind of review techniques are common in shift left and shift right?" and “How best do you motivate teams to shift left or shift right?”
2 Likes
10

My company is in the process of adopting a more Shift Left-Shift Down, so we’re trying to test earlier and with as little resource cost as possible, so leveraging more automation where we can. So for us it means…

Devs are working harder to ensure unit tests have better coverage, not just code coverage but different test cases for the code, and better standards for interfaces and factory designs.

Business Analysts, it’s learning not just our workflow, but adjacent workflows to see what up/down stream impacts we’ll have before we even right code and identify risks earlier according to business(event storming).

Quality Engineers, working on new quality activities to identify technical risks as we spin up new microservices or databases(risk storming), developing new forms of automation for quicker feedback before deployments(I built out testcontaiers/wiremock and I’m working on mutation testing) so that devs get quicker feedback.

Quality Analysts we let them run wild before we start developing an area so they can explore and learn the ins and outs of the application so they can be better informed and help QE and BA with different risk factors and basically have them become the application SMEs. Front loading with tons of knowledge so when we talk through sprints, they can start working with BAs on test cases and risk analysis.

2 Likes
12

I do like the use of Expand Left. I’ve also been championing Test Everywhere as opposed to using Shift Left and Shift Right together.

It took a little while to get stakeholder buy in for shifting testers focus earlier in the process as they have so often been seen as a final stage who you hand over new code to.

I found that as a lead I was able to gain trust and entry to earlier, higher up alignment meetings where I could raise quality and risk issues and make them think about the testability of a product and the reasons why we need certain testing efforts. By showing value they then happily embraced the move to testing throughout the SDLC

3 Likes
13

Partly Shift Left already exist , to practice more what QA discusses testing in parallel with each stage of the project, including requirements collecting, design, code increment products, integration of the interfaces, and the final product.

This help QA in understanding the requirement & write the test cases in the beginning which is also used by dev team to see how code behaves with corner scenarios & also gives us to automate scenarios in advance(to an extent not 100%).

ROI: We found bug during the initial phase & there is a drastic fall down of bugs in UAT and Production.

For reference:
Shift Left
Requirement gathering ------------------ Testing
Design ------------------ Testing
Development ------------ Testing
Deployment --------------Testing

1 Like
14

At testRigor we have extreme shift left where product managers write specifications in English that are executable out of the box. See Eliminate testing with Executable Specifications - YouTube

15

I don’t think it was me calling the change “shift left” since “shift left” was a term that was new to me.

Yep, all the QAs are being moved to a dedicated test team.

1 Like
16

So this is a Shift Right for the testers if we stay with the terminology. A bad Shift Left.
Moving the testers and their experience away from the devs, but leaving much of the responsibility at the devs. Which includes extending the feedback loop.
:sob:

wants to rant about how this is also a problem of the movements name, but stops here

17

I enjoyed reading @philippa’s comments on this topic:

Shift Left is a great term for some, but it seems to trigger fearful responses in some members of delivery, thinking the ‘buck’ of responsibility is being passed down the line and the current ‘tester’ is handing off all their workload onto others.

So, in my view, better than Shift Left - Think Quality. Think Continuous Quality.

Source and full text comment: LinkedIn

2 Likes
18

I read it over there and second it.
Thanks for sharing it here.

1 Like