What does shifting left have in common with TestOps? Both approach the same problem, just from different angles. Shifting left means that QA isn't just a checkpoint, it is a process that begins even before the software has been written and continues throughout the whole cycle. Instead of arranging the stages of product development neatly one after another, like pieces of cutlery on a table, we need to have constant interaction between the parts, like in a living organism. This means QA has to constantly keep in touch with the rest of the team, educate them on issues of quality, and be their backup gals and guys for the more difficult cases. Here, TestOps and shift left clearly agree.
Our own Ruslan Akhmetzianov had a very interesting talk with Parveen Khan, Quality Advocate and Senior QA Consultant at ThoughtWorks and an active proponent of the shift left approach. You can watch the interview on YouTube:
Or, if reading is more your thing, I'll give you the highlights of the talk.
Why shift left
The cycle of development starts with figuring out what the user wants. Of course, different teams do it differently. Sometimes, devs might receive a fairly loose description of a feature, and then just wing it based on their understanding of what's right and what's beautiful. But their vision might not intersect with what users actually do with an app. Figuring out what the users want and how they use the app in reality, tracing the user path - that's what business analysts and product specialists do.
Knowing these things is extremely important for QA: with that knowledge, you're no longer testing against a formal list, you're testing against what the user actually needs, which means you know where the priorities are and how to distribute your effort. It also gives you product knowledge. And in the end, this is the strength of a manual tester: knowing the product and being able to ask the right questions about how it works and what it lacks. Incidentally, this is also one of the main advantages of human testers over AI today.
The role of testers in shift left
Shift left is about marrying the QA mindset with the knowledge of user requirements and development practices. But sometimes that idea can be taken too far when people insist that testers aren't necessary at all; and, in fact, there are teams that do QA without dedicated testers, where devs write the tests. In such teams, devs write tests, and with observability tooling, you can immediately see if something crashes. On the one hand - whatever works for you; on the other - how about not crashing at all? The main problem is - devs and testers care about very different things, and apply their brains in different directions even when doing the same thing, such as writing tests. What occupies the mind of a dev are things like the beauty of the system, scalability, and readability. They think about how things should be, so when they write tests, they usually check the happy path. It's the responsibility of the tester to think about how things shouldn't be. They apply their creative and exploratory minds to finding faults. The developer tends to look at the product from the inside - because that's where they work; the tester has a broader view of the product.
This broad view of the product is one of the main things that a tester brings to the team. We've seen this many times with our head of QA at Qameta - Natalia Poliakova. When some feature doesn't work or just isn't intuitive enough, she goes to the UX manager and asks about the logic behind the idea. This has helped fix a lot of issues that the support team had in their backlog; more communication like this means avoiding those issues from the beginning.
How to shift left
So how do you go about learning from people in the first stages of development? You could go to sprint plans and backlog grooming sessions, as well as talk to business stakeholders and product specialists. When developers pick up stories, do a kickoff of the feature, where everyone comes together and asks questions - so that everyone is on the same page as to what the feature is about.
An excellent tool for learning is pairing. You approach the person you want to learn from and go - I'm interested to know more about what you're doing right now, can we pair on this while you're on it? This might not work out straight away, especially if people aren't used to this approach. It will take building a relationship, you have to show interest. But in the end, it can prove very rewarding.
This approach works best if you are specific and clear about what information you're after. Parveen has shared that in her experience, you have more chances if instead of trying to pair all the way you just do it when you can. If people are scared to do it - just start small; pick a specific role and see how it goes. However, don't be too cautious. Everyone is afraid of bothering other people, thinking that they have more than enough on their plate already. Relax - if that's the case, they'll tell you. You'll be surprised at how much people get excited about others being interested in their job.
Most importantly - share your own knowledge and expertise. At the meetings, when asking questions about what, specifically, needs to be tested and what test data needs to be prepared, you help people capture the tester mindset. In shift left, a tester is an advocate for QA.
One great way of communicating about QA is having a space in the organization where people can approach you, instead of you just going to them all the time. If someone wants to learn about testing, they should be able to come to you and ask the questions. And it's not difficult, 2-3 testers are more than enough to organize such a space. But nobody is going to tell you to do it, the initiative has to come from you.
Same thing, different views
For Parveen, shift left is part of QualityOps. It requires communication and education of different parts of the team. Devs can benefit greatly from knowing the actual user path behind the requirements that they're getting. Admins, just like testers, are advocates of their craft in this approach, and they help QA take control of their infrastructure. The main part is changing the mindset; instead of just handing the feature over to the next stage, follow it through to the end.
In the end, Parveen and Ruslan agreed that TestOps and QualityOps propose the same approach, but view it from different angles: TestOps starts with the tools and processes, while QualityOps is more holistic and focused on human interactions. Whichever you prefer, we hope that those ideas resonate with you!
