Welcome to Software Testing Unleashed, the podcast for testers, developers and software makers who live quality as an attitude. Get fresh ideas and sharp insights to grow your mindset, to learn new methods and to drive real change in how we build software. Better software and better teams for a better world. Hi I'm Richie, software quality coach, keynote speaker and author. My guest today is Kat Obring. Kat brings more than 20 years of experience in the software industry.
She has worked as a DevOps QA engineer, head of delivery, and today she teaches teams and how to measurably improve their quality. What makes her unique is her mix of practical frameworks and her coaching approach and her sense of humor. In this episode, we talked about the tester as an influencer. Why should testers stop saying "everything is broken" and instead learn to speak the language of their stakeholders? How can a 15-second check before a stand-up save weeks
frustration later in the sprint. And why are small experiments often more powerful than big transformational programs? We explored in this episode how testers can influence without authority, how evidence creates trust, and how tiny changes can build lasting habits. You will hear concrete steps and can try right away in your dream. And now enjoy the episode. Hello Kat, nice to have you here on the show. Hi Richie, thanks for inviting me. Yeah, it's a pleasure for me to have you here.
Because also you have a very interesting topic and I'm very curious, what will you tell us here about the testers? Because we gave it somewhere the title "The tester as an influencer". Yeah, it's very social media appropriate, isn't it? Yeah, it's true. So what do you mean with that?
Well, I think what I mean by that is that I think this is true for most roles in modern software development, but for testers specifically, is if you want to do your job well, and if you want to actually help the team create great quality, because quality is such a broad topic, you need You need to be able to influence people. You need to be able to make yourself heard and to get people to actually take seriously what you say and to act upon what you say.
Right. So and I think that is kind of where I'm coming from. OK, so it's yeah. OK, I can't imagine because also we as a tester have a lot of contacts in the whole stakeholder area, much more typically than other roles in that. Yes, absolutely. I think the other part of that is you need to be able to talk to your audience, right? And your audience can, like you say, it can be quite different. You can be talking to quite
different stakeholders. They're all stakeholders in some way or another. The engineers you work with, the product owners you work with, maybe you work with other teams, maybe you have a DevOps or ops team, right? And they all will probably value different things and they have different goals for their teams that are most important to them. And you need to be able to package your message in a way that it lands with them. And again, that is something where we, I think,
can learn a little bit from the influencer space. Yeah. And can you give us some examples on how to communicate with, you said to address the values from the stakeholders. Do you have any examples for that, for developers, maybe for managers? Yes. So I think, I think it all starts with being clear who you're talking to. So you don't go out there and repeat just the same message to everybody.
And I think sometimes people have a little bit of a tendency to just walk around as testers and say, my God, the quality of, you know, this release is horrible no matter who they talk to and that's not wrong maybe it is indeed horrible but that is not likely to land with people because what are people going to do with that so I think the first step is always trying to understand who you are talking to trying to understand what matters to them what
do they really care about right now bad quality is something that hurts the business but how does it hurt this particular person right what is the impact on this person or on the team that this person works with? Is it maybe for developers, is it more time they need to spend in fixing bug and in context switching because they will have to do work with that? Is it maybe on the other hand that a new feature isn't going to be adopted by users because it is hard
to use or they can't find it or it is very buggy? Or is it maybe that the The marketing team cannot meet their goals because people are not signing up at the rate they want to, again, maybe because the sign up flow isn't great. So all of these people care about slightly different manifestations of what we find. And it may be the same bugs we're talking about. Yeah. Right. But they have different impact on different teams. And I think that is really important.
Yeah. to get aware of this too, that we have to talk to the different stakeholders in a different way just to make a relationship also to them and then to bring out our topics we want to address with them. Exactly, exactly. And that is why I always said you need to start by understanding who you're talking to and then you need to frame whatever it is you want to say, whatever problem it is you want to present, You need to frame it in a way that matters to the person you talk to.
And then as a next step, I always like to bring a little bit of evidence rather than my opinion. Right. So I can say, I don't know, the sign up flow is broken, but I think to a product owner, it is much more interesting if I can go there and say, look, you know, this button doesn't work on on Safari, 20% of our users use Safari. So that means we're losing 20% of our users every time somebody on Safari, you know, go through this flow. That is no longer my opinion.
That is something that is based in evidence. And I think, again, that makes it much easier to convince people that this observation should trigger an action. - Yeah, I think this is one part we often mention not enough as a tester because also when dealing with developers and presenting bugs to them, we are often so happy that we find bugs. But they are not very happy to fix bugs and debug the stuff and so on. So to get one language that they can take it is very, very crucial, I think.
Yes, absolutely. And I think one language isn't enough, right? Yeah. You kind of need a slightly different language for the different roles and the different people you talk to. Now, I am all in favor of being clear about your language and meaning the same things when you use certain words. That is definitely something the team should agree on. So I don't particularly care if a team's definition of, I don't know, a test level necessarily alliance with any of the bigger test systems out there.
But I do care that they mean the same thing when they say integration test. Yeah, that's true. Yeah. Yeah. And I think it's one part to be in a relationship with someone and and get contact about their values and can deliver my message. But to go more to influencing, it's a step more, I think, isn't it? Yes, so I think then the next part is, so you are talking to this person, you have found an angle of a problem that you think matters to them, you have some actual evidence to present.
And I think it is a good idea then to think about a small change we can make to fix this problem. And I'm very much about small changes. So I'm not a huge fan of the 6 or 12 or 18 month quality transformation. I'm not saying those things are not well meant and well thought out. They often are and they often have very well established goals that would probably actually improve the outcome. Right. So that's not what I'm saying.
But what I'm saying is I think it is very hard for people to get excited about something that you need to a start blindly believing that it's going to make things better. And to do things and continue doing things where you only see the effect of them a long way in the future. And actually in the short term, it may make your life harder. So it's very hard to get buy in for those things. It is however quite easy to get buy-in from people for something that is easy to do.
Maybe you find a lot of bugs later because requirements haven't been well formulated. A constant problem in many teams I work with, right? Requirements are not well written. And instead of saying, "Okay, we need to change the entire system, blah, blah, blah, blah, You just say, OK, can we every stand up before we move a ticket from ready to in progress? Can we just as a team have a quick look and check that the requirements are in the ticket? Takes about 15 seconds, ideally, right?
If they're not there, you take three people and meet after the stand up and fix the problem. That is a change people can much easier, can get on board with much easier. And this may have a huge impact on the other end, because now you no longer have all of these bugs. You need, you kind of save time because there is no longer the ping pong between test developer and product owner. Should it be this or should it be this other thing? What should actually happen when I click this button? Right?
- I find it very interesting to think in these small steps because the example you brought with the requirements, when this problem is there, so there are typically two ways teams are dealing with it. The first one is to put a big review process on all the stuff. So to doing just four reviews, thinking about, and meeting, and workshops, and so on. And the other is to get more detailed in the requirements to write more text, which is also not helpful, I think.
So I like the idea to take a small step. And it's just a 50 second looking at the user story or the requirement to check, quick check, if it's OK or not. And maybe it's enough. Exactly. And then everybody who needs to work with this can go away and fix it if there's a problem to fix. And if you do this consistently, if you do it for a week or two, then it already starts forming a habit, right? And you're already on your way to making something better.
Because I'm all about changes where you can see actual impact of your change or can assess actual impact of your change, ideally within a week or two. All right, and then you can go and say, okay, does this make our problem better? Are we now seeing less problems with the requirements in our tickets? Or maybe it doesn't have your problem. Okay, fine. This is not the right approach. Let's try something else. Maybe,
maybe a template for requirements is the right thing to do. Personally, I hate them, but, but, but, but, you know, whatever different teams, different things work. So then you can try that. Then you put a template in there. And then again, you come back in two weeks and look, does, has that's changed your ticket? Maybe as a combination of the two who knows, right?
But small changes that are easy to pivot to maybe change or tweak a little bit, but also easy to abandon because you haven't invested three million in an 18 month plan. And it gives you the opportunity to learn constantly for the whole team. So with every one week, two weeks, you can, the whole team can understand, ah, we have to take care of this and that in the requirements and so on. and not just using another template could be one opportunity, but you can learn on it constantly.
Exactly, it's worth improvement, right? Yeah, absolutely. I think it's a very good example, because the requirements are often not so good as you said. What are the typical small changes we can influence, let's think into the direction of developers, let's say. Well, so for another thing is another thing that I often see in many teams, especially relatively recent converts to agile/scrum, right, depending on what they do, is that
the team start doing things that are basically mini waterfalls, right? You start a sprint, You kind of agree what you're going to work on in the sprint, developers develop, and then two days before the sprint ends, if you're lucky, all of the stories end in the test column and the testers now are supposed to test everything before the sprint ends. And that again is a problem I see fairly frequently.
And there are a number of things you can do, but I think the most important there is to stop separating testing from development work. Make it clear that testing is part of the development work. This is not, you know, like in our good old waterfall where we had the test phase, we no longer have a test phase. So you really need to start planning for this from the beginning and implementing it from the beginning.
Maybe you want to start your work on a new ticket as a developer or as a tester, you want to suggest to the developer that Why don't we sit down and pair on this for a short time, right? And then we can discuss how, how we can test the thing. So the developer can then do that work, keeping in mind that it needs to be testable, how it's going to be tested.
If there is anything needed to make it more testable, they can, you know, they know that from the start and can implement that it will help them write their unit tests because you can talk about those as well. Right. So that is another thing that is doesn't, it isn't a massive shift necessarily, right? But it is a fairly small change. Let's just start pairing earlier.
Yeah. I think there's so many small screws we can draw and adjust for the process to get optimized and better for development teams too. When I'm now a tester and sitting here and hearing and seeing that interviewer say, "Okay, that sounds so great, but I'm a little introvert Fortnite gamer and don't want to talk to anyone in my things." But I want, but I'm afraid of getting into contact or something like that.
So what are the first steps for me as a tester, as a quality people, to get into this role, to get more influential contact, to more relationship? How can I overcome this fear of... Yeah, so I mean, I will start by saying, I think this kind of very popular idea that people in software development are all introverts and that they don't like talking to other people, I think needs to die. Yeah, we had this episode with Isabel Evans a few days ago.
So if we cannot work in a team, then we are not going to be successful in this role. It is fairly simple, right? Now, I personally would class myself definitely as an introvert. I don't like going out particularly, right? So I spend a lot of time at home, blah, blah. However, I think what you need to do is you need to learn what works for you. How can you communicate with your people and what works for your team? Because it is not only going to depend on yourself.
For me, one of the things that really helped me is I started my career many, many, many months ago, working remotely for an American company. The company was in California. I was in Germany, which meant we had a bit of a time offset.
At one point I had already moved to the UK there But at one point I worked with half of my team in California and the other half in Indonesia So I basically took over to had a stand up with the Indonesian team at an end of their day I took took their stuff and then had to stand up at the end of my day with the California team and That meant a lot of the communication was written and that made it a lot easier for me Because that gave me time right especially
especially English isn't my mother tongue. And at the time I hadn't really worked with an American team before, right? So there was a lot to learn for me and being able to have this asynchronous communication really helped me. So that is maybe a good start. Then there are things where you can talk with your team and your team lead, right? Maybe you can have meetings that are not on camera and you find that helpful. So there are small adjustments that are fairly easy to make.
However, forget about the idea that you do not need to talk to other people because you will need to talk to other people. I think that's very important for the future too, to get more in contact and to talk to each other because we are sitting in our home offices and have no real contact to the people. So it's better to turn the camera on and to talk to the people and not just... I agree, yes.
But I know for some people, especially on the neurodiverse spectrum, right, for some people, camera is really difficult. So okay, that's fine, right? If it really helps you to not have your camera on, okay. I mean, you know, that's okay. Again, you need to talk to your team and you need to figure out what works and try to make as many adjustments as you can without actually getting in the way of a good flow of communication.
When you say to go to the small steps of change and to, from a testers perspective, to go on and talk to each other, when I talk to testers, they say often there is nothing working here correctly. The DevOps doesn't really work. We do not do really good HR stuff. They requirements are crap and the management says we don't need testers and test automation
sucks and all this stuff. So how can I prioritize as a tester, which is really a good step to go forward and which is maybe something I cannot have no control over it and cannot influence it anyway? So for prioritization, and you mentioned one of the things already, so I think we have more influence than we think we have. However, it is again, it is important that we pick battles we can win and that we pick, to start with that, we pick small
battles. So anything that is again takes longer than a week or two probably will need approval from somebody. Anything that is going to cost money is probably going to need approval from somebody. So pick something that you can do with an ally in your team, whether that ally is another developer, whether that is your product owner, somebody you get along with and you know they also feel the same problem you're seeing. Pick a small problem. Nothing is working is not a helpful statement.
It may be true, but it's not a helpful statement. So find something concrete that isn't working. I don't know stand up takes takes 30 minutes every morning because half of the team is late
That is that is you know, fairly fairly straightforward one. Talk to your team lead And talk talk get people to attend one time Right, or maybe I don't know Maybe in meetings xyz never gets to say anything, but they have the best ideas Right, then be the person who makes space for them I'd be the person who speaks up and says, "Hey, XYZ, what do you think about this?" Yeah, I think when I think about it, what you say, it's good for in this role to just grab a list
and write down all this stuff you don't like and where you see all the improvers and then do some evaluation about it. Is it evaluation? Is it feasible? Is it controllable? Can I do it? Is it a small amount of time and does it cost money? So do a little bit of assessment for this task and then you get the points where you can work on. Exactly. And this is exactly what I do in my, you know, what I call the QED question evidence developed method.
So it is really, it is incredibly helpful if you find a concrete example of what you think isn't working. If you can define this is the moment where we can see it is not working.
right because then then then you are able to ask a question around that and then you're also able to collect some evidence about what is the actual impact of the thing and once you have that then you can there are lots of plenty of methods out there right so i like liberating what they call yes exactly right so i like i like a lot of that but i also am a quite a fan of the good old
Eisenhower matrix, right? You do an impact importance assessment and it can be really quick and easy, you know, grab a whiteboard, grab some post-its, maybe a couple of papers and say, what is going on here? I think what I heard now the second time is to do something more quick to get a decision to what to work on. So I like the approach not to overthink all the whole
stuff. So when I think of the Eisenhower matrix, I can do so much stuff in it. I can define and all the segments and the quadrants and do my prioritization and have to do big workshops. But when I hear you, you always mention that to get a quick result, which is maybe not perfect, but to have a result to work on for the future. I am very much in favor of quick results and I'm very much not in favor of trying to get things perfect. You're no enemy of Dan and all of that.
I mean, I come from a DevOps background, right? So I'm all about A, metrics, but also doing quick experiments, quick, easy experiments that are simple enough that they can be easily abandoned without having cost a whole lot. Because if you have too much, if you have to invest too much, whether that is time or money or thought, you get very married to your things. And it makes it really hard to be somewhat objective about the results from your query, right?
Because now you're invested, you want this to succeed. I think good experiments are the experiments where you know what you want to change. So you need to know what success looks like. But they're also easy and cheap enough that if you can't reach success with that, you can like, eh, fine, let's try something else. Yeah, that's a great approach.
And I think one thing we have to mention here, we talked about upfront, is that you have also a course available in the short future, which helps test us to get into more this influential role of in the project. Yes, absolutely. So I teach this. It's a six-week online course. So it is six 19-minute sessions online, live with me, where I teach people the QED, Question Evidence Developed method.
And what we do is, so what I give people there is structured tools to ask good questions, to look for the evidence, to kind of frame their stakeholder conversations and then how to go about collecting the evidence for their experiments, right? And the way this works is we develop some problems that they have in their everyday work.
So when this is not a highly theoretical thing, people can bring their actual work problems and I teach them how to apply all of these frameworks and methods on their actual work problems, but they can go away with something they can work on in their everyday context. So that is what I do basically. That sounds great and very interesting. So we will put the information for this course in the show notes too. So maybe someone is interested and then can book it.
I can recommend it here what I knew from you. You are such a great expert in this stuff. So I think there's a lot to learn in this course. I've done this a few times. Kat, thank you very much for this insights in this interview about how to get an influencer as a tester in the project. So I like the spirit and I like the idea to get use of this role in the project more to make things better. Thank you very much that you were here and I hope
we see us in the future in real life. I'm sure we will, unless of course everything explodes and you can't fly anywhere anymore. Yeah, we don't hope so. So we will see, I think. Thank you very much. - Okay. - Bye-bye. Well, thanks, Richie. It was a pleasure. Thank you. Bye-bye.