No More Gatekeeping: I’m Here to Coach, Not Catch Bugs - by Christine Pinto

In this talk, Christina Pinto discusses the evolving role of quality assurance (QA) professionals, emphasizing the transition from being perceived as 'bug police' to adopting a coaching approach. She outlines the importance of fostering quality as a team effort rather than merely identifying and fixing bugs at the end of the development cycle. Pinto introduces the concept of a 'quality coach,' advocating for collaboration within teams and encouraging developers to take ownership of quality through understanding risks and business implications. She provides practical strategies for implementing quality practices, such as empathetic communication and using AI as a supportive tool. Ultimately, Pinto's message calls for QA professionals to become integral to the development process, influencing early-stage feature discussions to enhance overall product quality.

Challenge accepted. [music] Challenge accepted. Challenge accepted. P2 [music] is always challenge accepted. And now it's time for our next speaker. And may we say this year our stage is more beautiful than ever because for the first time we have three lady speakers in one conference in one edition. Let's hear for that. [applause] But that's not all. For the first time we have a lady nominated for the

QA of the year award. This deserve a grand applause. [applause] Our next speaker is someone who has been breaking things for nearly two decades and fixing a few along the way. She's a tester turn tech founder, the CTPO and co-founder of Epic Test Quest in Berlin. >> She blends AI with human judgment, turns testing into a team sport, and helps testers evolve into strategic leaders. When she's

not revolutionizing QA, you might find her picnicking under cherry blossoms, at a classical concert, or carefully building Lego Harry Potter castles brick by brick. Please make some noise for >> Christina Pinto. [screaming] Accepted. Challenge [music] accepted. Welcome. >> Thank you so much. And I think also big applause for these well-dressed two gentlemen's and these awesome introductions. Thank you so much. Let's see if we are connected. Yes,

we are. Just quickly change that. Chop and chop. Perfect. Now I just don't see my slides, but we're going to make that work. Well, thank you so much for that awesome intro, as I said, and I'm so excited to be here in beautiful Sophia. It's my first time in Bulgaria and I'm very welcomed here and I'm so impressed. It's a lovely city and lovely people. And I'm

so excited to also share a topic which is very, very close to my heart, quality coaching. because I'm here to coach, not to catch bucks. Raise a hand if you ever been called the buck police or something similar. What about if you've been told testing slows us down? This is not just your story. It's our story as testers. And here's the hard truth. When the industry sees

us just as buck police, there is no wonder that the headlines look like this. These are real headlines. QA roles being cut, job post vanishing, and analysts saying half of our work will be automated by AI within a few years. But here's the truth. The problem isn't you. The problem is how our role has been boxed in as the last line of defense as a buck police.

The future isn't about guarding the gate. It's about stepping onto the field as a coach. Helping teams build quality together, not just finding the bugs in the code. In the end, that's the real story behind this headlines. The old image of QA might be fading, but what's emerging is bigger, more valuable, and absolutely needed. But before I dive into, let me introduce myself as well. I'm Christine

Pinto. I have been working as a software tester for over 18 years in different industries, startups, government in government entities, and distributed teams in Germany as well as all over the world. I'm also the ambassador of the Ministry of Testing, one of the world's biggest testing communities. More importantly, I'm also a proud co-founder and CTPO of Epic Test Quest. ETQ is creating an awesome app right in

Teams and Mic and Slack to turn your specs, screenshots, and chats into instant and actionable testing artifacts. We want you to spend less time buck hunting and more time coaching. We are prepping our alpha testing phase to be started in one week and I'm super excited to do that. If you wanted to know more about that, chat with me afterwards or send me a message on LinkedIn.

Let's dive back into the slides. How many of you have experienced that exact moment? Midnight before release, Slack is blowing up and we're just at can QA just quickly verify the lock in flow, the registration or something like that. This is why AI looks so threatening to us because if our value is only the last minute safety net, guess what? AI doesn't need sleep. AI doesn't care

if it's been called up in the middle of the night. But if the value is preventing this midnight panic from happening in the first place, well, AI can't do that. If we stay in this trap, the headlines we saw will keep getting worse. But if we step out of it, if we shift from guarding the gate to coaching the team, then suddenly QA does not become the

last line of defense, but the spark that keeps quality alive every step. So let me show you how that looks like in a quality system. I've seen many teams do this. I call it the quality crusade. One passionate QA trying to push up a hill, finding that one bug, finding more, and finding to catch everything. But crusades burn people out. They build heroes but not habits. What

scales are rhythms, reviews, risk assessments and also decisions guided with shared confidence. And that's where we as quality leaders step in not as gatekeepers but as crossf functional coaches. We help the team build the habits. Oh, that light went on. uh build the habits, ask the right questions and also see the signals to make quality a team muscle. We don't need to convince more people. We need

to give them a system worth following and especially someone to take it root. So what does it really mean to move from gatekeeper to coach? First, it means coaching the team on risk thinking. Not just does this work, but what can go wrong and how bad could that be. It's about to show the developers the risks that you see. You most of the times see the whole

picture, the whole product, but developers not. So help them see what the risk actually means when this sorting or this lockin does not work. Second, it's about enabling developers to own quality. You don't run behind them with a clipboard. You have to give them the frameworks, the tools, the habits, and most importantly, the confidence to build quality themselves. And third, it's about connecting quality to business values

because bo bugs are not just technical failures. They are broken promises to customers. And when you make that link clear, when you express and explain that an oath problem can come to a customer churn in the registration, which in the end means less profit, the leadership will lean in. They will give you the money and the time to go into this new role of a quality coach.

And that role is not the goalie at the end, but the coach on the field to multiplying the whole team's impact. So, if the old role of gatekeeping doesn't serve us anymore, what does? I want to show you the new toolkit of a quality coach. Think about it as superpowers or the spell book. Not abstract traits, but practical skills you can do on day one when you're

back in the office on Monday. Empathy, system thinking, change coaching, databacked intuition, and continuous learning. These aren't just buzzwords. Each one of them is a way to move from buckfinder to team multiplier. Each one of them gets even stronger if it combined with AI. And AI is a valuable tool, but only if you use it well. So let's explore how the first superpower is empathy. But I

don't mean being nice. And trust me, I'm from Berlin. I know what the difference is. What I mean is the ability to take conflict into collaboration. At the heart of it, trust builds If the team trusts you, they will let you into the real conversation. But without trust, every time you raise a bug, they will think you blame them. You're pointing the finger towards them. You will

just try to find something to make them look bad. A simple way to start is just ask the question, what feels slow? It's not about catching people out, but about inviting them to share friction points. That one question can flip a defensive developer into your partner. And your partner can also be AI. It can help you draft nudges or even role-play tough conversations. Imagine practicing that somebody

sells you as we see in a lot of have testing slows us down. I reck very defenses to that. I was like no that's not true. I want but that's not the right way for collaboration. That is again conflict. But now AI can help you to go through three different kinds of versions how to do this talk. So when that talk actually happens, you practices it and

most important you can go in there with confidence. That's empathy and practice. First trust, second curious questions and AI in the corner to help you with the hard talks. Most of us only see the tip of the iceberg, the 20% bucks, failed tests, production issues. But the real problems, the majority leaves lies beneath the surface. The misaligned requirements, the rush development or QA which got pulled in

way too late. If we only chase the bugs, we are fixing the symptoms, not the causes. This is where a coach mindset really matters because instead of asking how do we fix this, we look into it and ask what in our system on our process made that bug happen to be in the first place. And AI can be a partner here as well. It can spot patterns,

find causes. You can feed it defect locks, commit history or jira tickets and it can cluster these patterns. FYI here, very important. Don't copy or don't put any company secrets or intellectual property into an AI tool, especially if you're not allowed in your company to use an AI tool. You have to start learning basically to frame it a little bit more generalistic. I will show later show

what I mean with this, but really be careful. Don't copy. Like I said, if it's not allowed, don't copy your geo ticket one to one in the AI. That would be very bad. Um, when you put that in into the eye, it basically can highlight the weak points in the process. And that's the difference between firefighting and creating a system which prevents fires I used to see

a problem, create the perfect solution, and try to roll out all at once. Guess what? That failed badly. Because the truth is people don't resist change. They resist being changed. And that's why I now treat every experiment, every improvement, every change as an experiment. Instead of a big roll out, I say, "Let's try pairing on a story kicker for one sprint. If it doesn't help, we stop."

And that changes everything. It feels safe. It gives the team a co-ownership. And because it's framed as an experiment, it doesn't trigger any resistance because experiments are fun. So what's what that's what it shows here in the loop. First, we plan a tiny change. Then we try it out for one sprint. We reflect together on what happened and we adapt and we take only the things which

actually worked for us. How you can use AI here? It can suggest simple experiments. You could try maybe a new retro format and it can create quick summaries of what you worked on and what didn't so that the team can see the progress and keep the momentum. This is how change sticks not by force but by safe experiments that grow into shared Too much noise, excuse me,

too much data is just noise. Dashboards, charts, defects count, they all look very, very busy, but they don't really change anything. What matters isn't more data. It's finding the one signal that helps the team make the decisions. For example, don't track 20 different buck metrics. Pick one leading indicator like how often does testing happened right before the release. That's a signal that can shape behavior. And the

power here is in translation. Don't just say we had 43 bucks last sprint. Say late testing created a lot of rework. But when we tested earlier, our delivery actually got speed up. Suddenly this gut feeling, and I'm pretty sure you know this gut feeling, especially shortly before the lease, you find all of these bugs is not a good feeling. That gut feeling with this story finally speaks

the same language as your product manager and your leadership. AI can help you cut you through the noise. Surface that one signal that matters and then most importantly it drafts a tailored story around it. So people don't just see the numbers, they see the actual impact. Because data doesn't drive change story do story do and the right signal told well can shift how the whole team works.

This is the most important power the one AI can never take. AI is brilliant in repeating patterns. But curiosity asking what if that is human. When we experiment, when we explore sideways, when we ask the odd questions, that's when breakthroughs happen. That's when we find the bugs AI would have never predicted. That's when products become usable and not just functional because we know our products in the

end get used by humans. Start small. Bring one new idea into the sprint. Ask a bold whatif question in the planning or take something from outside of a comp from outside of your company, an article, a podcast or maybe something from this presentation. And here's the beauty. AI can feed you into that spark. It can draft prompts, suggest experiments, and summarize. But the spark to try, to

learn, to push forward, that has to come from us. Because being a quality coach doesn't mean we have to know all the answers. It's about sparking the questions that keep the whole team learning. Fact is when we act like gatekeepers, teams wait until the end to involve us. They put up walls, work around QA and in the end we end up isolated and bought up way too

late to change anything in the outcome. But when we act like coaches, the walls come down. Quality shifts from being a final hurdle to being part of the daily team's conversation in the planning, in the delivery, in the pairing. It's there at every step and the payoff is huge. Shared quality means faster delivery because instead of scrambling at the end to catch up, we are preventing rework

and late surprises before they even happen. That's the culture shift from being a checkpoint to being a coach. And that's what changes the whole game. We've just seen how quality creates momentum when the whole teams owns it. But m momentum also depends on the role we choose. The stakes are high because how we show up can either trap us in old patterns or unlock something bigger. If

we act like a buck police, we are stuck fixing symptoms after it's too late. But if we become people who are not just chasing the bug, if we step up as quality champions, we prevent problems from even happening. That's the shift from fixing late to guiding early. And that's the real reward. And as testers, it's very tempting to think, oh, can I just do more faster, speed

up? I can try do more checks, more tests, go on through this quality But like I said, that doesn't scale. That only burns you out. The real power is enabling the whole team. When we coach developers and product owners to think about quality, we move further together. and the impact multiplies. And here's the final step. When we can't coach every team with the same script, we cannot

use generic strategies because they don't stick. Believe me, I tried that. What works? We have to tailor the practice to your team because that's how change last because it fits your team's reality, not just our theory. Now, many people say the most uh scary thing is jumping out of an airplane. They never tried live prompting in front of an audience. So, cross fingers that everything works, the

Wi-Fi works and everything. But we will see. I'm going to show you a prompt you can use with Jet GP Claude. It has three parts and this is the first part I wanted to show you. It's where you put in placeholders. Says I'm a QA because I believe the team size is very important. Then I'm working on and that's for example a mobile app in the finance

sector and then I'm using a methodology because it's very important I use encumber scrum or waterfall then my main problem is xyz and our current testing pro process looks like maybe the handoffs don't work or maybe we tried already specific things important here is try to be as uh detailed as possible again don't expose any um secrets Because if you put garbage into the AI, you will

get garbage out of the AI. The last one, I have a specific amount of hours per weeks for the improvement. Because I can tell you AI can make up a lot of beautiful plans, 36 pages of plans, but that takes its own full-time job and you don't have that and then you get immediately very frustrated. And the last one is are your developers cooperative, resistant or mixed?

because that will also change what power you are using. Now let me see. Perfect. Let me just make that a little bit bigger. And this is not working. Oh, one second. I just need to stab it. Perfect. Can everybody see it? Okay, perfect. Thank you so much for the feedback. So, we put in here um a 50 person 15 person team working in an enterprise SAS platform

in scrum. The problem is teams doesn't work together. Well, I had that very often as a problem. And then my process right now is separate deaf and QA phases with poor communication handoffs. Very common for enterprises as well. I have six hours per week, but my developers are very resistant. Now, that next part, I haven't showed you that yet. That's basically the explanation of the five testing

superpowers here. Very important. This should grow the more you're using it. Like I said, tailor it for your team. This is now my definition also from the presentation and how it worked for my last team. You should adopt this every time also to learn how this fits the best to your team as well. And then we see the five things I want to get out of it.

Pick one power that fits best and very important explain why because this prompt is there not to replace you but that you can learn from it and that you can also get a little bit feeling what actually fits in a later time. and then give me one practical step that I can take tomorrow because that's always good and then show a specific way AI could assist here

very important while I stay in the lead and then suggest how I can measure this whole thing and what I also like very important is g give me a combo move I use by the way here claw but in the pro version I'm not sure I think the four one is also possible as a free version now let's look it's analyzing it and it's suggesting us that

we use Power number three, I think that it's very good as an idea because make stick without make change stick without force fits very well because our developers are very resistant. So that's the first focus. Then also it suggest a bark archaeology experiments. It also explains what it is. Another one how can I assist very interesting it suggests completely different things than when I tested yesterday. That's

why always life prompting is always fun. Um I think very important here also and another one measuring success. It is important to really find the data to tell your story also from the other power we know because it's suggested here. Tell a story with data. Very important. This is just a start. Um I can sh I will share this on my LinkedIn in the next couple days.

The full prompt that you can also copy it from there. Use this as a start. Use the chat to also then continue maybe saying okay I tried this already. It didn't work. It's just not as nice. Use it as a start and then see where this goes. It worked quite well for me and I hope it will be working well for you. Let me switch back into

the Now one one second I use my arrow here back. Perfect. So all right let's make this real. If you're wondering where to start, you don't need a big program or a perfect plan. You can start your coaching journey in four weeks. Just two sprints. Week one, shadow one developer. Ask them to walk you through their story and find one possible risk together. In week two, start

a conversation. Ask a simple question in the planning like [snorts] what feels risky here. Already sparking that tone alone will change a lot. Week three, pair test. Really pair test on one risky feature together because then you show that quality shared is way better and brings you way faster to the goal. And week four, share what you learn in the retro to know then also what you

want to adopt. That's all four small steps. You don't need to be a gatekeeper. You just need to coach one spark at a time. If you remember nothing else from this presentation, I hope you do, but if you don't, just keep these words, three words in mind. Courage. Try one small coaching move, even if it feels uncomfortable. purpose to see your role not as fading away but

transforming into something more valuable and pride because you're not becoming obsolete. You're becoming essential because the truth is teams don't need buck police. They need quality champions because in a reality way I create slop faster than ever. You are more important Thank you for joining me on the start of your coaching journey. Connect with me on LinkedIn if you have any other questions and hopefully we have

still time for one question. >> YES, WE HAVE. YAY. >> I have never seen such good on >> Exactly. I left five minutes. >> Three, two, one. She said thank you. >> So you have three minutes for questions. Any questions? There is a hand there. >> You have a questions or want a t-shirt? >> just give me a second for drinking something then. >> Uh can you

hear me? Good. >> Yes. >> So issues are often tied to technical debt, older or ra low quality code and refactoring it would require big effort which business doesn't want to allow. uh how would you advocate for technical rep depth removal to the business before it gets too bad the changes get too slow or we basically end up needing a rewrite >> a very good question technical

depth is something which we all have problems with and there's very important that translation hey because all of us in the room I would say no the more technical depth it's getting more and more complicated but leadership does not see this always so we have to from the now I hope Don't mix them up. Uh, superpower number four, tell your story. You have to bring data, but

you have to connect it to the business value. That really it worked like a charm. The moment you and you stretch because you can, and I tried this, I put in basically a very technical how I would talk to my other QAs or developers why technical dep is not good and then basically give it the role. So now be behave like a what are the big um

consultancies PWC or whatever behave like that kind of consultant to a leadership round what would I say because you need to use their terms customer churn you need to use profit loss only that they will hear and I can tell you because I did a talk about quality leadership uh in London that's exactly what I spoke there to the CTOs it works the moment I say customer

turn like oh god what is a customer churn what do we do oh god oh god oh god oh god oh god so That's really because technical dep it's just it gets bigger and bigger and bigger. You get so many problems but you can also um write me a message on LinkedIn because I have a beautiful uh flywheel to explain it even better. You can take that

as well. Thank you for the question. >> Thank you. >> Thank you. And the last question in the hall there is a is there another question? >> Any other questions? Oh, I see back there to the left. >> Okay. >> Yay. I love so much woman power here. >> Thank you. Hello, it was a great >> Uh my my question is about uh what would you recommend

for the involvement of QAS in the business process before actually it becomes a bug? So before a feature is developed and when should the QA be involved in the development of the feature? >> Yeah, it's a good question. I believe as early as possible. I um with one minor thing because I worked for example for a cryptocurrency wallet. I was not able to do the discovery for

example the earliest as possible normally starts when they do like discovery because I wasn't a subject matter expert I was would have been very wrong at that part but the moment we are they go into their planning actually before that kickoff meeting that's when you can ask these like gut feeling question okay what if he does do this what if it's like a a new no what

was it I think we added a new sorting feature and and a new whole new thing about uh you see NFTs I have no plan about cryptocurrency even though I work there Um it's when you're sitting there and even don't know what it what the topic is you you have this gut feeling and when you come with like curiosity and when you come also with like how

can I say that it's a light way of saying these things hey because you don't again it's it has a lot about pre-work. So if you done the pre-work, you built the trust. You had the coffee chats and they are like very nice with you. They don't see that you blame them. Be in the planning. be in the planning is actually I would say in the kickoff

with the product manager and the designer and one developer to figure out okay we implement that now you should know most of times the best also how the customer is that sounds very good but have we thought about I think the example before the internet explorer people like have we thought about these should we maybe bring marketing in so as early as possible I know everybody says

this and I know it's not so easy that's why you have to do that pre-work if you don't if you don't have a trusting team if they have and especially if they have bad experience if they have like what is my most loving example a developer does half developing and half QA I know there are really lot good developers who can do that but also a lot

who then just don't do QA at all so that's always the problem try to be as but trust is the very very important thing I hope I could thank you for the question >> thank you very much you can find Christina in the speakers corner now in the break please make some noise for Pinto Hello. Great talk. Great talk. Thank you very much. [music]