Hello and welcome to a new episode of podcast software testing. I am your host Richie and have brought you an episode on the topic of software test leadership today. I talked to Kari Kakonen about test leadership, who has been involved in the software test for over 30 years, trained many thousands of people, was awarded conference prizes, wrote books and is active internationally.
He developed the model ACT2LEAD and wrote a manual that can be used to implement this software testing leadership approach into practice. As a small goodie, of course, there are a few copies to win again. And now have fun with the episode. [Intro] Hello Kari, find a dear year. Thank you. Good to be here. One week before we were in Bali, the ICTCB and now in Belgium.
Meeting in such a short time. And I saw there in the ICTCB meeting you presented your book and your model about testing and lead testing. And yeah, and I think it's a great topic to talk about here. It is. Yeah, it is. Yeah, so I will give you the word. So what is this model about? So it's ACT2LEAD. And the background there is that I think there is not enough leadership in testing. I mean, teams are managing testing, teams are doing testing, that's like in a grassroots team level.
So it tends to happen quite well, but it's not really led as in, you know, great opportunities are created or culture for good quality and good testing is enabled. That sort of thing is not happening in a big scale in companies. So all too often when I go and also I have a co-author, Marko Rytkonen, who I co-authored this book with. We've seen over our careers that all too often when you go to higher level companies, you realize that they actually don't know about testing.
They realize testing must be done and they might require, "Yes, you need to do testing," but then it's not really understood. And you could say that the more you understand about testing, the better you can lead it, the more you can enable people to do good quality and you can expect good quality. So you need to lead it actively. You need to make it happen. And so that's why this act to lead. And again, why act to lead? Why do we call it act to lead?
It's because if you want to have something easy to remember, something that it's easy to implement as well, you need to have a short way of saying how you can do that stuff. How you can make testing happen all over the companies and not only with testers' minds and testers' daily routines. So that's why act to lead because that's a heuristic. So that's like eight characters and each character means something. So it has everything in it, really. So A means add testing to everything.
So again, testing is not only happening when you get code and when you test. Testing is actually happening when you think about your budget of a software. Testing is happening when you think about what kind of a vendor or supplier do I hire to create software for me. Also, you need to include testing in that thought process or decision. And then you want to think about what happens in production. How do I operate my software? Again, you are testing and you need to think about testing as well.
How can I make sure it works? How can I check? How can I test it actually works? So that's A. Then there is C. So C is context. Testing is not everything or same in every place. It's different based on context. So you need to understand your context. Context-driven testing, context is everything. You need to understand what kind of business it is, what kind of domain, what kind of technology, what kind of team, how much money. Are we in a hurry or not? And it really depends.
And you need to choose your testing based on your context. So that's C. T is transparency. So whatever we do, we should do it visually. We should give information to everybody. We shouldn't hide if we are doing a lot of testing or a little testing. We should actually be thinking about, let's share our testing to everybody. If we find defects, let's share, but we have problems with quality. Because then you have better chances of everybody helping and pitching in and creating better quality.
But I think there is also the part of aggregating this information. So we have a lot of information metrics and defects and all this stuff to make it more fitted to the audience. Oh, yeah, yeah, yeah, definitely. So, yeah, let's not give all the details because people will have information overload and that's not the idea, of course. But still, let's not hide either. Let's make it available. Let's create the dashboards and whatever. It's easy to understand ways about our quality.
And especially, I think it's very visible if you have multiple stakeholders in the play or multiple vendors or suppliers in the play. It's all too easy to have borders and boundaries. But, okay, they do their thing. We don't know exactly what, but we have defined in a contract what we need to do as part of testing. And, okay, let's just trust them on that. And, you know, so transparency there means that, you know, let's not only trust. Let's actually make it visible. What do we require?
What do we get? What is actually happening? So that's the transparency part. Okay, then we have a fourth character, and that's two. And that means that we always need automation and human being. We need both things. So it's definitely you can't have only one of the two. Even though today's world is going towards automation all the time, so, you know, more and more test automation, more and more delivery automation, CI/CD pipelines and all that. It's not only that. You still need human people.
You need exploratory testing. You need creativity. You need new ideas, and these are coming from human beings. So you need to find a way in your own context to fit in both automation and human beings because you need both. So that's number two. What do we have? L. L is learning. So it means that you can't know beforehand what is actually needed. You need to test, and through that you learn how the software works, and you learn also how to make maybe test better.
So you need to learn to test and test to learn both ways. That's very, very interesting because I wrote a blog article last month about this testing is the profession that you learn a software product deeply so you understand what it has to do. It is. It is. Exactly. We had just a nice discussion earlier today about are testers like very focused people or actually are they broader people?
I think testers are actually very broad people because they learn about the whole software and where it fits and everything. I think if you need to ask one person, "How does this software work? What is this software all about?" You actually should go to the tester because the tester has the big picture. Having thought of it from many angles and risks and how it should work and how it actually does work. Because the tester needs all this information for his work. Oh, yeah. Exactly. Exactly.
That's exactly so. So that's the learning part, and I think it's quite important. It's not the most important because the next one is actually I think the most important part, and that's the E in the tech act to lead. That's enable testing, enable quality culture. Actually create the circumstances where good testing can happen. Make it a rule that you should test well. Make it a rule that you should talk about problems and failings and learn from that and not blame people. Every day do that.
Don't forget to mention testing all the time or mention good quality all the time. The higher you go in a company into the top management, the more important it is that people keep saying that testing is important. We need to think about quality as well. It doesn't mean that a CEO of a company would be doing hands-on testing, but they should be actually talking about testing and quality and not letting it be a responsibility of a team only.
I think it's a big cultural change for a lot of companies to go there. It is. It is, definitely. It's too easy to say, "Yeah, we have some testers. They do what they do." Then you realize, you ask a CTO, "What do we do?" "I don't know. I suppose they run some test automation and do some checks." "That's a good start, but it's not really enough."
Because if you would ask, "What do you think the developers do?" Or maybe, "What do you think the architects do?" Actually, the answers would be more precise. They actually do know how you create code or you use management or you use Python there and C there and Java there and whatever. Actually, the answers are usually more precise. I think it just proves that there's a lack of testing knowledge. That can be fixed. What else do we have? A, adapt to risks.
All of testing actually should be based on risk. High focus risk areas, more testing. Quite simple. That's really the last A, adapt to risks. Then also we have D. That one is, I think, second most important after the E. That's diversity. Meaning, testing needs to be diverse. Diverse in every possible way. Use multiple test techniques. Use multiple people. Use multiple test approaches. Use multiple kinds of people. Multiple suppliers. Multiple environments. Anything multiple.
The more, the better, basically. You can't choose only one approach. This might be thinking of a manager somewhere. "Okay, give me the best choice." "We'll make the best choice, best something tool or best something approach." "We will use test automation for everything." It's not like that. Because you need all kinds of things. Different angles support each other. Then you actually have good quality. I have often the picture of if you're in a cave with a flashlight.
Just put the flashlight in and you see one spot there. But you don't see the cave. You have to look at different angels and different perspectives to get the whole picture. Yeah, it's a good analogy. It is, definitely. So that's why we have to act to lead. There's not too many things there because I think in the end, the higher you go in the companies, you don't need to know the detail of testing.
But you do need to know enough so that you can be active in the relationship between the business and running a company and then requiring software. When somebody is creating that software and testing that software, you need to know enough to be active there. And this acronym, I see that also as a checklist for you and my company, my organization. Who is in charge of this job? Is it the test manager who's looking at this or the CEO or the CTO or a consultant or a coach?
Well, it depends on the context. But in general, I would say that there is a demand for a role in a big company who is in charge of testing. So that could be head of testing, for example. So all too often there is the CTO who maybe used to be an architect or a developer or maybe just a business guy, and that's fine.
But somebody needs to be taking care of testing because if testing happens only in those teams and if teams are self-organizing only, which is great and fine, and I believe in autonomous teams quite a bit, that's really good. But if all the teams are taking care of their own testing and they have different ways of doing it, in a big company I don't think that's enough. You also need somebody who is in charge of testing.
It's wrong, but it's taking care that testing happens all over the software, well, developer software, but it's much needed. So it comes down to having somebody there like head of testing, having some general testing guidelines, not really dictating same rules to all the teams, but giving minimums. You need to do at least that much. And then you need to find your ways in your team, in your context, how to actually apply those.
And it could be testing communities, people sharing their ideas with other people interested in testing. And I'm saying testing, not testers, because I think testing is also something that anybody can actually do. Yeah, that's so true. So you wrote a book about this model, and how deep do you go in each of these segments? And what do you deliver with EG4 enabling for this stuff? Quite a bit, actually. It's actually surprisingly heavy, heavy book.
So its subtitle is "Software Testing Leadership Handbook," and it is really lots of information, like almost 300 pages. And it is made in the form of questions, because very often when you want to find answers, you don't know exactly what you need, but you have your question. So it is actually questions. How do I make testing more diverse? How do I cope with testing terms? How do I recruit testers? So things like that.
So it actually goes more deeper than just those eight letters, but the eight letters are a good start, and they can make you think about these things. So the book is actually--it goes really deep. And even before we actually wrote it, we see the CTO or CXO level person stereotype in our minds, and we've seen lots of people on that level.
It actually turns out we wrote so much content that it works also for any test manager or tester, or even a student in IT who needs to know and learn a bit of testing. It also works for them. I think I like the approach to make it with questions, like a big FAQ, because if you go to test and look at it, you have questions, and if I have a normal book, so I have to read everything and transform it for myself, but with this question I can more relate to the content. Exactly.
And if you are in a hurry, if you are a busy person-- and I appreciate that any--let's say CEO is a very busy person. I don't expect every CEO to read every detail about everything that happens in their company, but I'm sure they have questions, and I'm sure they can read the summary, and I'm sure they can deep dive into something that they have a worry about something. In this book, there's the answer for that, and in an easy-to-read format.
It doesn't yet teach you how to test, so actually we on purpose cut away all content like that, so when we were writing it, we noticed, "Oh, now we're actually writing towards the tester or the MSN. It goes more technical and too technical," and we actually ditched maybe like half of the chapters because they were just not right for the CXO level kind of thinking or need. So great.
Yeah, and we discussed upfront as a little goodie for the listeners and viewers of this podcast channel, you said we can give five exemplars of the book to our audience. Yeah. So you can look at the show notes. There is a link, and you can do maybe and win one of these copies from you. Absolutely. So that's, I think, a very nice action here. Absolutely. Yeah, Kari, very, very much. Thank you very much for joining this podcast here. Thank you so much. Testing retreat was very interesting.
It gives me another perspective, like we said, another perspective on testing and how to implement testing. So thank you very much to be here. Thank you so much. And, yeah, we will see what our testing retreat will be bringing to the next. It will be so much more fun. Yeah, I think so. Thank you. Thank you.