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.
For that to work, QA has to constantly keep in touch with the rest of the team, educate them on quality issues, and be their backup gals and guys for the more complicated cases. Here, TestOps and Shift Left clearly agree.
Ruslan Akhmetzianov had a fascinating 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 here.
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 beautiful.
The problem is that the dev's 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.
With this approach, you also get product knowledge. 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. In fact, some teams do QA without dedicated testers.
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 that 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 just check the happy path.
On the other hand, the responsibility of a tester is 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 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 isn't intuitive enough, she asks the UX manager about the logic behind the idea. This has helped fix many issues 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 learn from people in the first stages of development? You could go to sprint plans and backlog grooming sessions and 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 about the feature.
An excellent tool for learning is pairing. You approach the person you want to learn from and go: hey, I want to learn more about what you're doing right now; can we pair on this while you're on it?
This might not work out immediately, 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.
The pairing 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 pairing - 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 they already have more than enough on their plate. 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 needs to be tested and what test data needs to be prepared, you help people capture the tester's 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 will tell you to do it; you have to take the initiative.
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 they're getting.
- Admins, like testers, are advocates of their craft in this approach, and they help QA take control of their infrastructure. The important part is changing the mindset; instead of just handing the feature over to the next stage, follow it 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!
