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 Gitte Ottosen. Gitte is a test and quality coach with more than 30 years of experience in IT.
She's known for her strong focus on value-driven software development, both in traditional and agile environments. Kit is a dedicated trainer in Agile and Testing and a regular speaker at international conferences. She is also a passionate advocate for context-driven testing and helping teams develop a true quality mindset. When she speaks, it's not just theory, it's backed by decades of practice.
In this episode, we talked about the reality of cross-functional teams, quality engineering and being aged, what does it really mean? Is really everyone responsible for quality or does that mean no one really is? Are we building deep skills in teams or just a long list of shallow ones? And what happens when AI takes over the easy stuff and we've forgotten how to test the hard parts?
We explored the tension between specialism and collaboration and why trying to do everything can make us good at nothing. Gitte shared her perspective on the shift from testing to quality engineering, what Scrum actually says about team roles, and why structuring thinking still matters in an AI-driven world. You'll also hear how testers can drive improvement by asking better questions, supporting others, and bring critical thinking back to the table. And now, enjoy the episode.
Hello, Gitte, nice to have you on the show. - Hello, Richie, nice to be here. I'm really glad to get a chance to discuss about some of my favorite topics. - Yeah, great, and I think the community will like it very much. (Richie laughs) We talked up front and there were so many topics you can talk about, so I think we have to do a lot of podcast episodes together in the future. We might do another. There's many things to talk about in our craft or profession. Yeah, that's true.
Yes, we chose the topic about talking about the cross-functional teams and how they are doing nowadays and in the last 20 years and the evolution to up to now, and if we are going to the right direction, so if I frame it. So, yeah, so you did business now a lot of years and decades. So what's, how do you think, how did it evolve the last centuries? Yeah, actually, I had my 30th anniversary on May 1st. So I've been around a bit.
And I mean, when we started with implementing Agile and Scrum in our, at least in the company where I worked, we took our test team and we put the testers out. them, they became a part of this Agile team, but they stayed with their testing profession. We start talking about the T-shaped, okay, so you have to have some abilities that can support your team with doing other things than testing. I became a Scrum Master as well,
and I helped the PO with the requirements. And that was sort of our way to contribute to the agile mindset of delivering value. But in the later years, we've seen, at least I've seen here in Denmark, a movement in many companies starting, I use the term, they're implementing mechanical agile. So what they're doing is they read the scrum guide, actually, they don't read the entire scrum guide, I know for sure. And then they just implement some roles and some ceremonies
artifacts. But if you ask many scrum masters today, and unfortunately a few coaches as well, what does the Agile manifesto say? Or what are the 12 principles of Agile? They don't know. And I mean, that's the foundation for the cross-functional team is the knowledge of why are we doing Agile? And that is actually the problem is we are doing Agile. We are not being agile. We're doing it like it's, it's just a hack we put on and then we are
agile. And then some reads the scrum guide because they say, Oh, but it says it's a developer team. So since it's a developer team, we don't need testers. So we get rid of all the testers. I've seen companies fire all the test managers. I've seen them fire their testers because now the developer needs to do everything because scrum says it's a developer team. But the The thing is, that's not what Scrum says.
In the Scrum guide, it does say it is a developer team, but it shouldn't be read as it's a software developer. It's a team member who has some kind of specialist knowledge that can support the ability to deliver value. So it could be anyone, including testers. So that's some of the anti-patterns I've seen. And now here in the later years, we've started talking, especially the last two years, we start talking about quality engineering. And I like the concept.
I've just, I got to start with saying that I love quality engineering and a mindset that quality is everybody's responsibility. And I love the thought that if I have a high performing agile team, then the team takes a full responsibility and they do testing as well as anything else. And they have the competences to do so. But if I look at the teams that I've been in connection with over the last many years, none of them would be able to do that. They are hopelessly lacking competences in test.
So when you start saying that the quality engineer is not a person, quality engineering is something we put on top together with all the other stuff we are supposed to do in the Agile team, then I worry. Because most Agile teams do not have the maturity to do that. They don't have the competences to do that. They need some kind of help. And do you think it's also a part of the responsibility? So if you say to give a team the whole responsibility
for something, nobody's doing it. So is this also an aspect of this? I mean, that is definitely one of the... It's always dangerous when you say that everybody is responsible for something, because who then takes that ownership? Do they as a collective group do that? And not all do. I mean, let's face it, for many developers, tests above unit testing and maybe unit integration testing, it's not their thing. That's not why they took the education they took.
That's not why they have the skillset they have. They have the skillset because they want to develop software. And then there are people like you and me who loves the other part, who loves testing, who loves all aspects of testing. And I think we should look at the teams and enable the team members to thrive at doing what they do best and what their passion is. If you let people do what they're passionate about, then they become good at it.
If you force people to do something they are not passionate about, it's not going to be good, not the result at all. And I don't say with that that they shouldn't do testing, because of course they should. Of course they should do testing, but they need the skill set and they need someone to support them. Yeah. Yeah. And I think it's on the other side, we load on the testers a lot of stuff they have to do now if they think more quality and not just testing.
So they have to take care about helping developers with their skills for designing unit tests and integration tests and doing static analysis and take care of some code reviews and do all the quality stuff. So the pure testing part, the concrete thinking about what we can test, there is no time for that. No, no. And I mean, I think we should, first of all, I think it would be amazing if more
universities dived into testing as a profession and as a skill set than there is today. But also universities recognizing that testing above unit and unit integration is actually interesting and relevant as well, especially in which so complex systems we have now. But as a tester in an agile team or as a quality engineer, yes, you do get a lot of different
tasks. And I hope that what we do is we help, we enable the developers. So for a period of time, we will focus our energy into helping them become more mature in figuring out what to test and becoming better at doing unit tests. And then slowly we can move away from that and take what is rightfully what we could do best. I mean, I can't do unit tests, the unit integration test. I've never written a line of code in my entire world, but I can tell them about structured testing.
I can help them understanding that, and then I have to ensure that the tool set they have will support them in doing what they're supposed to. So yes, for a period of time, but if you have an unmature agile team that has no control over their quality, you can't fix it all at one time anyway. got to start somewhere and why not start from scratch, which is unit and unit integration test. And then as that matures, you can move your focus elsewhere. We can't fix everything at once.
I'm so I've we talked about from from I shaped to T shaped. And I'm so concerned that we that we are we are making people too broad. And when people get very broad, they don't get very deep in the competence level. There's a talk about pie shape as the mathematical simple pie or M shape. So you have three deep competences and that's doable still. But I've even heard people talk about comb shapes.
So the comb you use for your hair and you think about the number of teeth, a comb path, but then again, look at the length of those teeth. They're very, very short. So when we expect that everybody is supposed to do everything, then nobody does anything really good.
Yeah. And I think this is, this is then also right for the developer as for the tester, because the developer maybe has to do some test automation stuff for doing this and that and write scripts and maybe support a business tester with some ideas. And so it's always getting very broad then. Yeah. Plus, they have the responsibility for the tooling in the teams and for the pipeline. And if you, that's a Danish cartoonist, who Comic Agile or Comic Agile, and he has an amazing drawing called
the Agile Team's Cognitive Overload. And it illustrates it perfectly, because it's not just a tester who has a challenge, we all have. When we start saying that everybody has to do be able to do everything, then nobody does anything really good. And that is not what we should strive for. We should strive for excellence in our fields and then we should be able to support our teams with other things than what is our deep competence. And that is what Scrum says, by the way.
And what do you think, how can we find this balance in the team between not going too broad, but to have the expertise, but also to support this? Where is this, how can we find this boundary over this? I don't think there's one. I think it's really, really context dependent. For example, a tester like someone like me who has no technical background, I can't help with the coding. I can't support the pipeline.
I can't review unit tests because of course I can recode to some extent, but not with the skillset needed for that work. But what I can do is I can support the product owner in writing good acceptance criteria for the user stories. I can review the feature descriptions and support that the intake we do. I deliver my value outside classical testing terms in the beginning of the development model by supporting the product owner doing good requirements.
If you then have someone, another tester who has a technical background, who can do test automation. He can help with that. He can help with unit and unit integration tests. He can maybe support the pipeline. He can do test automation, but because he is also a good tester, he still knows about structure testing and test design techniques and exploratory
testing. So it depends completely on where you are, what you're doing. Sometimes if you're sitting, I've been sitting on the customer side of projects as well, where I have no discussions with any developers whatsoever, because there's a strict line there, then my assistance is out towards the business, trying to understand what are the workflows that this system should support, drawing the process diagrams, using them, of course, to
testing, but also introducing my vendor and thereby their developers into these different processes so they understand what they built. Because that's what we can do as testers. We get a much better understanding than most others of what is the system actually going to be used for. And I mean, we've talked about building quality and shift left buzzwords for the last, what, five years? And that's what it's all about, right? Understanding the value that we are going to bring.
That's the first principle of Agile. Our first principles of Agile is to deliver value to our customer, to our end users. And if that's, then what is the best we can do? Help up front, ensuring that we understand what that value is. So it's a huge deal, a challenge this one, because we need to make it visible for others value we can bring other than pure testing. And that's what quality engineering really is about, right? It is about supporting the team in delivering value to our customers.
So the mindset of quality engineering is amazing. We just have to remember that most of us don't live in the perfect world. We live in the real world. We don't live in unicorn world. live in the real world where things are not mature. Where the foundation we develop on, the user stories, the feature descriptions are horrible, if at all existing, when there's no acceptance criteria, when they just say, you just do whatever you did last time, or
you go figure out what you want to implement. Where developers, we might have developers who's been sitting there for 30 years, who never worked with testing before, and who are not interested in working with testing. There's so many different ways, there's so many different contexts. So we can't just say quality engineering, that's just something all do. Start with figuring out your context. Yeah, I like the thought to align the work
with the delivered value in my role and from my perspective. So what can I do for the team and for the product to deliver value to the customer or the user and so on. So I think that's a good thought to take into the project. Exactly. Have you seen the Jerry Weinberg originally defined quality and then James Buck and Michael Bolton added on it and I love their definition because quality is value to
someone at some time who matters. So what is it we can do? We can get to know the people who matter And we can figure out how do we deliver value at some time? What is the right time to deliver this value and make it visible to our team what the value is that we need to deliver? Our why. I mean, that's where Simon Sinek, start with why, right? Understand why we're building what we're building rather than start with figuring out how are we going to implement it?
How is not interesting before we know the why. And I know it's a lot of buzzwords, but we should do that in practice. Yeah. And so when someone hears now this episode and says, "Okay, yeah, we have especially this problem in our team now. Who is in charge to change something there?" Because when HR, we have no project manager or something like that. I'm just a little tester here. So what can I do? How can I bring this process improvement into life for my team?
I mean, in the new team app, they have developed two tools or methods for continuous improvement that I like a lot, because I think if you really want to move a team, then each team member needs to understand what is their share in delivering quality. And they have made two different, they made quality to activity mapping and quality to people mapping.
So you make a workshop with your team, if we take quality to people mapping, then they have six key areas, something about quality awareness, something about automation, something about infrastructure and so forth. There's six different areas. And then you put the roles out in a matrix. So these six key areas down the first column, and then up in the top, you have the different roles in a team, developer, tester, business analyst, whoever you have. And then each person brainstorms over.
So what is my share in these activities? And how can I add value? What can I contribute with? So you get that dialogue up and running. And then when you then have your whiteboard full of post-its with things different people can do, you can of course not improve everything at one time. So as a group prioritize, where do we start? You can do it on people or you can do it on the different DevOps activities. So what quality aspects are relevant in the different DevOps activities as well.
And I like that because then it's again, it's the ownership of the team. Teams have to figure it out because they are responsible for quality. But it becomes transparent to them that they do have value to bring to the table. So I like those two. And it's enabling the communication between the team members to get this topic aware for everybody in the project to do such a workshop or something like that.
Yeah. And I like the fact that it's not something that is pushed upon them from the outside, but it's something that it brings an awareness to the table for them as well. Because very often when people hear quality, they think testing. Test is a part of, but not, I mean, there's quality assurance, there's quality control, there's testing, right? Quality control and testing are shared, right? So there are many other things we can do.
When I come back to the picture of the comp, where we have these skills, very short skills there, I have to think about that we are talking now that AI will take over all the junior stuff. And I see that these comp things maybe are things that AI can do too. So maybe we need more of this expertise for specific topics. What do you think? What is your relation to in this combination of cross-functional team and how can AI support us there in the future?
I think AI can do a lot, but I also think we need one of the most important skills we have as testers. We need the critical thinking mindset here. I've seen in our own company some of the things we've been working with around reviewing user stories and acceptance criteria, generating Gherkin scenarios. And that's, it takes a lot of, it can do a lot, but it still takes someone to take a look at it. So is it right?
I think it was World Quality Report that had a, some year recently had some numbers. And one of the things they had asked different companies, what they saw as the role for testing QA in the future, where they sort of saw the tester as not the shepherd, but the reviewer, the gatekeeper of the quality of the output of the AI. But at the same time, in another table, they had looked into the competence level of test professionals, and that one's
going down. So how can we become shepherds or guides or gatekeepers or whatever if we don't know about testing? Our level of competences, I mean, I know test design techniques sounds old-fashioned, but it's so important. If you want to do effective and efficient testing, you got to know those. You've got to know your test design techniques. And I don't really care whether
you use them for exploratory testing, whatever you do, but you need to understand them. Sitting there reviewing the output of a test design made by an AI without understanding the test design technique, you don't add any value whatsoever. So we need to understand that if we want to make a difference moving forward, supporting AI, we got to step up. We got to be professional. The teeth in our comb should not become short.
We should not be comb-shaped. We should be maybe N or M-shaped, two or three deep knowledges. Yes. But we are not supposed to be able to do everything because then we're not not good in anything. Yeah. So, it can help, but we need a skill set. Yeah, I think that's also true because when we think about testing, it's building trust. And we as people, as testers, as human testers are there to give this trust that we can trust our quality and the software we're delivering.
And so we need this expertise to review the outcome from AI and all this stuff. How can we give our stakeholders the confidence that what is delivered and sent into production adds the value that they expect and is safe for them to use if we don't have the skill set to test it, to ensure that what they ask for is actually interpreted into something that makes sense and that whatever the AI does is following in that direction?
I mean, I've been playing around just with basic chat GPT for these examples where I actually asked it to use test design techniques. But because I understand the test design techniques, I caught it in doing things wrong several times. But that's because I know techniques. It actually made too many test cases, way too many test cases from what I asked it for.
So if we want to be sure that we have a good set of tests that can be supported with exploratory testing, that can be a part of our regression testing, then we need to understand what it's doing. Yeah. And why it chooses what it chooses. Yeah. And when I'm now a tester in this team and say, "Okay, I want to shape my skills for the future, what would you recommend to learn for a tester to give more value to the team and for the product?
I have a long list. I mean, I said it already, understand your test design techniques, at least a handful or two of those. Understand them to the extent that you can use them as a part of your daily work and that you can see in the output of an AI if it's wrong, because you know what's expected to come out more or less, right? But also still get a better understanding of what exploratory testing is, because so many people coins to say, okay, but we're doing exploratory testing.
But when you poke at them, they're not, they're doing ad hoc. cannot really because it sounds a bit like people think that with exploratory testing we can just say, okay, we don't need structure or anything. Yeah, you do. You just don't document it in scripted test cases, but you use your critical thinking and your new system thinking, your new test design techniques to make the best possible test of something. you're still structured, you're just not documented. So that's important as well.
Understand how you can use test design techniques as a part of documenting requirements. So if you're going to support a new, many people implement standard systems, right? They got to support a lot of different workflows, business processes. How do we come from a process drawing to test? Ensuring that we have a sufficient that we tested sufficiently and not too little and not too much. Process cycle test. Risk-based testing. Yeah. Oh yeah. That's a good. Oh we
could do a whole podcast about it. So many says they do it and so few do it. They do the product risk analysis or the quality risk analysis but that's not about it right. So how do we go from there to actually figuring out how to address the most effective and efficient set of tests. That's also because the thing is very often we test too much. It's not that we test too little. We actually often test too much or test the wrong things too much, right?
So understand basic. I mean I just look at my bookshelves over here, right? I still like physical books. So test the science techniques, exploratory testing, Understand risk-based testing. Understand the do's and the don't. Be good at prompting. Understand how do I use CheckGPT or Copilot or whatever as an effective and efficient tool to support my daily work without leaning back and say now it just takes over I'll just copy paste and put it uncritically
without reviewing anything because that's my fear. Just look at my look at But some of the articles we see being, people let ChatGPT write the article. So use it as a tool, use it as a support, understand what it's strong at and where it's not strong. Yeah, I think we can learn a lot for the future. So these are all topics I want to mention in future podcast episodes too. So I think there is a lot of learning and also to relearn some things of my foundation level or something like that.
I heard about all these test design techniques, but that doesn't mean that I use them. So maybe I have to relearn them or more train them on the practical way to use it more in my projects. Yeah, maybe you don't need to go and have another training course. Maybe you can read the material from the course you did. You can find some YouTube videos, you can find some e-learning, whatever. And then sit down with someone else. And say, OK, so this is the documentation we have.
What technique can we use here? And then try. It's the best way to learn. I mean, I'm an old scout. Learning by doing, right? We can read so many books, we can do so much training, but what really makes a difference is when we take what we've learned and we then try to apply it in practice. If you don't, then learning is a waste of time. - Yeah, that's true. Yeah, great. I think that's a good word for the end and for the future.
Thank you very much that you joined the podcast here for the interview. And I'm very sure that's not the last episode we will do together. I'll be more than happy to participate another time if we can find a funny topic to discuss. Yeah, we will. So have a good time. Thank you very much. Bye bye. Bye.