Stop Finding Bugs, Start Improving Business: A Masterclass with Alan Page

David Burns: Quality comes from the system you make and the system is the culture, the rewards, the incentives. If you reward the team for going really fast and deploying 57 times a day and then don't care if there's quality issues, you're gonna get what the system produced. As a tester, you lean into it. Your job isn't to be the bottleneck, the safety net, the person behind the horses scooping up their crap after the end of the parade. Your job is to help the team ship customer value faster. We can do much better than AI. is have that curiosity. That's the skills that software really needs and the AI isn't going to replace it. Quality is a lot more than functional correctness. And AI can help a little bit with that. Welcome back to Browse the Stack Tool, conversations that turn testing pain points into playbooks. I'm your host, David, and today I'm joined by one of the foremost people in the technology space for the last two decades, Alan Page, who's kind of done everything from development to testing, but I can't introduce him properly. Alan, please introduce yourself. I don't know about foremost that that's a little, but I'll talk anyway. So I'm Alan. I've been in tech for a very long time, worked at Microsoft for a long time, did a lot of work in testing and quality there, also led some groups doing internal training and consulting, moved away from testing into engineering leadership was at Microsoft where I found I had often more control over quality. I just did a post today by the way on testing. I forget the title, something controversial around like testing isn't quality. are different things. Anyway, Microsoft, worked at Unity Technologies for a while. ⁓ I did a couple things there for about six, six, seven years. Worked at ⁓ NBC Universal after that, interesting place. And then last April, I took a little sabbatical and I walked from Mexico to Canada on the Pacific Crest Trail. Had an amazing time and amazing people. And now I'm a... I'm home in Seattle enjoying briefly while I kind of began looking for my next role, playing a little pickleball with the retirees, going to the gym, taking long walks with the dog, things like that while I ease my way back into the real world. So there's me in a nutshell. Nothing in there screams foremost to me, but I have been around. And one thing, if you know me, you'll know. And if you don't, you'll find out in the next 40 or 45 minutes is I have opinions. Perfect. And those opinions are why I wanted you to join us today. we'll dive straight in, right? And this is where I kind of feel like the foremost really stands out. You kind of did a lot of work around the modern testing principles, kind of did a lot of work there. also, I think the phrase I think you used is that you meant it as an antidote to traditional testing. Right. Yeah. And so, and as you said, you have opinions, some of them controversial, some of them don't think controversial. Here's the thing, they're not really controversial, yet they are because they manage to piss off testers sometimes. let me talk a little bit about where I podcast partner, Brent Jensen, and I came up with these and why we came up with them. So of course, Agile has been around for, I can't do math, almost 20 years. mean, since Probably more than 20. can't see time as a drunk slinky. maybe about 12 or 15, oh about 15 years ago, somewhere back there. was beginning to, Brent and I worked there, was beginning to have more teams doing agile kind of work. Not a lot of, the service teams especially, teams like Bing where Brent worked was a good example. And we saw at the time when I wrote how we test software at Microsoft, Microsoft had about 10,000 testers, about one tester for every developer across the company. huge number. And that was sort of how companies were put together back then. But we noticed that things were changing. as teams move faster, by the way, please note the parallel with AI, as teams move faster to deliver, the role of testing was changing. There was no time for testing to be the safety net that tested quality in at the end of the product, which some people will say never happened, but they're lying. was the way things worked for a while across the industry, including Microsoft. And we saw that a lot of testers were asking these questions like, well, how does my job change? What do we do? How do I keep up? Do we test a sprint later than the developer sprint? And answers were no, just chill and think about it for a minute. You're supposed to be a systems maker. So Brent and I were talking, we talked about it for a long time, how testing was changing and how, what roles testers could move into to kind of take advantage of the new world. How do you take the skills you have and maybe do less actual testing a little bit and actually help as we put it, accelerate the achievement of shippable quality. And what that turned into was, there's a long story here. I just read Ray Dalio's book on principles, principles, we need principles. So I sketched out these principles. said, Brent, I think these are our principles. And we vetted them out live on our podcast. And we eventually figured out we kept these modern testing principles that aren't that modern, they aren't about testing. They're really about delivery. And they actually line up pretty well with the three ways of DevOps, if you're familiar with those. We're just trying to talk about how does testing change or how do testers change and how do we deliver software in this faster way? with the onset, remember the, by a little footnote a minute ago with people are, and you're probably seeing this too, David, the same questions and concerns and freak outs testers were having 20 years ago with the onset of agile. It's like, ⁓ my God, we're delivering so much faster. What do I do? They're all history is repeating itself. AI assisted development. ⁓ my God, they're delivering so fast. What are we going to do? And it's the same thing. you, as a tester, you lean into it. Your job isn't to be the bottleneck, the safety net, the person behind the horses scooping up their crap after the end of the parade. Your job is to help the team ship customer value faster. And that's what the principles are about. They're all about delivery. They're about how to focus on improving the business. don't get in the way, accelerate people. But that moved into a lot of the work that Janet Gregory and Lisa Crispin have done around test coaching and helping other people on the team understand more about testing. It's all fit in very well with everything going around it. And like most things I, air quote, invent, I find that I didn't invent them as much as discover new words for things that were already happening, but it does fit in there. And that's kind of the history of what they are, how they fit in, and also kind of why they're more relevant than ever today. short answer there for you. No, I think that was brilliant. Because I agree. The way I've been phrasing it is kind of the misquoted twain thing of like, History doesn't repeat itself at rhymes, right? Like it's one of those. I heard that just last week too. That's great. It's perfect. Yeah. I think it's often attributed to Mark Twain, but I don't think that's quite correct. Correct. That's what I read when I looked it up as well. Nobody knows where it came from. But the thing is, I think it's really important, as you say, like there's a lot of this repeatable information. It's all about moving fast as what do I do? How do I do it? You know, it's like, well, as you said, move back to system thinking, where's the risk? Where's this? Where's that? And then focus in on those things along the way. And risk doesn't mean the code. could be the way you process and things like that. And one of the things you said there that I kind of wanted to narrow in a bit on, and I think this matches up with what you were saying about AI as well, is that like you stop being quality police. Stop. And move to coaching, guiding people, right? And everyone says, you know, quality is everyone's job, right? But sometimes people don't know how to do quality. just go, I've a ship. Yeah. And I maybe lost track with the questions in there, but I'll answer the question I heard anyway, which is, yeah, I think 30 years ago, think Brett Petticord wrote an article called something around stop being the quality police. ⁓ And here we are. scroll LinkedIn more than I ever have because I'm kind of curious what's going on out there. I also, you know, glancing at the job market, but still I see posts from testers on basically saying, we need to be the quality police. So that needs to end just hard stop in there. I think probably the other thing worth mentioning there is that everybody the whole thing, if everybody owns quality, then nobody owns quality, which has some truth to it. What I found, I hinted at this before, as I moved from running test teams and kind of consulting on testing internally at Microsoft to managing infrastructure, where I found I had more control over quality, more levers, as Elizabeth Henderson would say, I had more ways to control quality. When I went to Unity and I owned larger and larger teams, I found that in leadership, had more influence over quality. And if you've been reading, I've been writing a lot of newsletters since I got back from the trail. And I've been writing a lot about quality as a system. quality comes from the system you make. And the system is the culture, the rewards, the incentives. If you reward the team for going really fast and deploying 57 times a day, and then don't care if there's quality issues, you're going to get what the system produced. Yeah. I'm finding more and more that, and again, I'm not going to say it's leadership's rep, you know, there's folks on LinkedIn that are elsewhere that they want to blame every single thing on management. And that's not fair either. building a culture and incentives and rewarding the behaviors you want to see has a bigger influence over quality than anything a tester or a test team can do. Yeah. No, I think it's everybody's responsibility, but it's the leader's responsibility to create a culture where quality can thrive. Yeah, I agree. The way I always phrase it to people and it's every business has this. So it's not like I'm putting any one business down. It's like the way people think about quality. There's a lot of overlap with kind of how Conway's law works. Do you know Conway's law? Conway's law is your org structure matches your product. or vice versa. Yeah. But it's interesting. Oh, yeah. The I see it from the other side is that like your your product matches your old. Yeah. That's what you said. But yeah, like the whole thing. Yeah, it works. Yeah. And then you but then people go you need to have a QA or can then let's like, Okay, cool. This now that's a separate part. And then how does that influence it? And I think Yeah, going back to your first print, your two principles and that you were talking about, like delivering quality must be having like where you're going to write. So like, what is the business impact that this is going to have when you deliver this? And how is that going to be really useful? How can you how have you kind of guided people into thinking that through like, you know, what you're delivering is not necessarily quality, but it's the end product. Like how are you guiding people to those in your past and things like that? I'm going to use so many name drops and quotes in this podcast, but one of the pop and dykes said, ⁓ customers don't want software. They want their problem solved. Yes. And I think a lot of times in testing, whether it's developer testing or often in a test team, they're focusing too much on functional correctness or trying to make sure, and I can think of so many Microsoft products that you have examples on where they make perfectly functional software that nobody likes to use. You have to understand, again, functional correctness entirely 100 % responsibility of the developer. Beyond there could be developer or tester, but functional correctness fully the developer. A quality product solves a customer problem. And so if you're wanting to, from the principal side, if you want to make sure you're delivering a quality product, you need to take the time, ideally through customer data, whether it's interviews, whether it's telemetry, some sort of ⁓ information you have, and figure out from the quality point of view, don't even say testing, is this solving the problem that we think customers have in a way that's intuitive and easy to use? I just had a slight discussion, small discussion on LinkedIn recently about this. there's testers, know, originally if look at the literature, it says that we should, we as testers, the voice of the customer. And what I've learned, again, the modern testing principles, what I've learned is if you're not using customer data and insights from customers to understand how they're using the software, you are guessing. at being the voice of the customer. You're not. No matter what, you're not the customer. You know who the customer is? The customer. Are you the customer? No, you're not the customer. ⁓ Maybe a little bit different with if you're, I think it's a little bit different if you're working on developer tools and maybe as a parallel you can find here. ⁓ Sometimes you are the customer, but you're not all the customers either. you can look at the data of who's using what parts of your product and what features are using it, how often they're using them and guide you're testing around that and have a lot better chance of making something that's going to help the customers. Yeah. The phrase I use, I believe this came out of Microsoft, is like, I do believe people should be dogfooding their own. Yeah, dogfooding was the original thing. That worked really well for Windows, and I worked on that because you're using the daily build of Windows to build and debug the next day's version of Windows. But for me, the whole point of dog fooding is that it leads to what you said, getting those data points, right? You go, ⁓ actually, I have this, right? ⁓ And I'm a big believer in data trumps anything else, right? Like data doesn't have feelings. Your feelings do not matter to data. It will run over them no matter what, right? ⁓ Sometimes data can be wrong. You probably have known them. John Jansen worked at Microsoft on Internet Explorer. And he famously told me a story about collecting data where there was an off by one error in, I forgot, the local database that you used to be able to install in Office 95, 97, things like that. can have a little... remember it. Yeah. ⁓ And, you know, there was tools to be able to get your own information out of it. And then the telemetry was sending ⁓ back everything, but there was a one off by one error. So they went and said, ⁓ we need to improve this one thing. And but no one was using it because they were using the next one. There's another that access, but there's another great story on the Visual Studio team. They looked at their telemetry and. They saw, now I forget what feature it was. ⁓ It was something really horrid. But they saw, ⁓ a lot of people are using this feature. It's working, it's working. And then if you looked a little deeper at the telemetry, you saw that the number one command by far after using this command was undo. So you need to take your data, you'd look at your data in context. We're doing the thing. ⁓ And Office found the same thing. They found that, ⁓ If you remember, in fact, I haven't used an office app in so long, but number one command used in office apps is paste or control V. The number one command used immediately after that was undo because it would, when you paste into word, it would paste the original formatting sometimes and oddly. people said, no, not like that. No. So you do need to look at the data in context. It does help you figure out what people are doing and where to perhaps do more testing. Yeah. And I also think there's a lot like ⁓ testers and ⁓ UX people, they have a lot of things in common because they really need to be looking at the same data and trying to get the same ideas and product people, right? Because they go, ⁓ okay, I've been using this incorrectly. Let me go try this. ⁓ wow. They should be using shared dashboards to look at customer data everywhere. Those three groups. Absolutely. Developers too. mean, we used I think a good one of the signs of a good software development team is they have dashboards everyone uses to understand how the customer is using the software. Yeah. Yeah. And like, and I'm a big believer in getting those things. And even in open source projects that tends to be a little bit harder because open source people uses of open source go, why are you trying to collect my data? It's like, just want to make it better. It's not that I actually care. Right. Yeah, it's yeah, I get that. I get I get the hesitance of folks to do that. But it does help for the folks to do use it. It does help. Yeah, I usually am. Anyway, how do we get here? Yeah. Yeah. So talking going back to kind of UX people, product people, things like that. How have you in the past actually like just To me, a lot of these things make sense. I try to get my teams to do it. But how do you go get a junior engineer, kind of senior tester, go, actually, this is what you need to be doing, how you do it? How do you guide them to the culture that you want? I think you never let them first. You never let them start in the culture that your job is to do a bunch of checkbox testing. Especially today, when AI can do that checkbox. That kind of work. AI can do for you. So I think ⁓ you start them off in a place where especially with junior engineers and I've coached both junior testers and junior developers. You start them in the same place. pair them a lot. give them, I mean, I'll speak very generally, you can give them small tasks to do that they can do on their own. can come back and talk about what they learned. think, I don't know how you started. think when I first started in testing many, many years ago, I was just sat in the room and said, test this. I had no idea. And we figured it out. had so many testers started that way. We had no idea what we're doing. OK, this is fine. I'll figure this out. This is wrong. I think this is wrong. Whatever, whatever. Those days are hopefully over. If you're a manager and you're starting a tester or a developer off that way, even a developer wouldn't say, OK, go program this feature. Let me know when it's done in a week. Like, never. You would never do that. So with any junior tester, ⁓ To get them going in this direction, think the best thing you can do is as a coach or a mentor or a manager is pause and ask them to look, ask why, look at the bigger system. When they see a bug, 30 years ago, if tester found a bug, they'd go, yay, they'd enter it and that'd be it. I think what's, and some would do better than that at the risk of those posting mean comments. I think what's really more important is like, I'll pick a bug. This UI element is off or it's makes it think of something better. Tab order is wrong, it's a stability issue. Oh. So that happens and it's often enough it's an easy one to find, okay, this is wrong. Oh, and I just enter a bug. But the thing to think about is, I like testers to do this is think about why. And it could just be they missed it. Is tab order wrong everywhere? Has tab order ever been considered? Can I figure out if tab order has been an afterthought or just the fact it works is a stroke of luck? It's never been thought of. Are there static analysis checkers, hint there are, that will find these things in web pages on check-in? How can we prevent this sort of bug from ever happening again? These aren't senior things. The thing is the junior may not know those things exist. but I want to teach them how to ask what if, what if I had a way to catch this earlier? What would make this easier to find in the future? How can I make it so I never have to find this kind of bug again or it's rare that it happens? And they may not know the answers to those. think you and I have been doing this for a while. We know we can find 10 tools to do this on GitHub in 30 seconds. So the answer's out there, but it's, we talked about our friend Ash Hunsberger a while ago. Ash and I had, Ash worked with me at NBC when I was there. And one of the conversations we came back to a lot was, you teach curiosity? And we think the answer is yes, but some people are more naturally curious than others. So as I get to the, those that know me, I give a very long answer to get to the answer that really has some meat. I think what I'm trying to do with juniors is foster and encourage curiosity. It isn't just about getting a task done. not going to again, to go back to the system. What I want to reward them for. I don't want to reward people as I was when I first started for finding a certain number of bugs every week. Bug bounties are stupid. ⁓ I want to reward their curiosity. Like what else, when you found this bug, what else did you think of when you, what do you think would lead to this bug happening? And now I'm talking about anything more than does not necessarily tab order anything. I want to get them really thinking about what causes quality issues in software and maybe even ask them like, so go ahead and enter the bug on this. We're going to track that. But what's a conversation? This is, this is from David's code. What's a conversation you go have with David about this? ⁓ That would be, I'm trying to, I want to teach those interpersonal skills as well. Like how, how can you, how do you want to present this to them in a way that you can understand more about the circumstances that introduced this bug. Things like that. That's what I would do with juniors. I'm trying to get them to be not only good at what they're doing now, and think about this. again, my LinkedIn feed is skewing me. All the people have done the exact same kind of testing, asking the same questions for 10, 20 years. I want to prepare these folks up so they're, I want to prepare them for a long career in software engineering, whether that's testing, development, UX, product design. And to me, that comes in what, What we can do much better than AI, for now at least, is have that curiosity. And that's the skills that software really needs and the skills that AI isn't going to replace any time soon. So that's what I'm going to foster and try and coach into them. I like that. And on a previous episode, I had Marit on. And Marit said something similar. I love Marit too. Yeah, she's so freaking smart. Yeah. And her phrasing to this was like with AI, with tooling, things like that. I really just want to give people to get people to a state where they have more time to be imaginative. And tools give you the time to be imaginative. Right. And to me, that's very similar to what you said is about curiosity. And I do think curiosity is really important. Right. I appreciate like the job is nine to five. But a lot of the times it's just like, what happens if I did this? And not being afraid, just go do that. And I think that ⁓ leads to some things being interesting. Like when you start going, ⁓ I need to collect data on this. And you go to the point of, what happens if we just push this to production and then see what happens when I end users to it? ⁓ Some people call it testing and production. Some people call it the shift rides, you know. And there's benefits to both, right? Like I don't think you said it earlier. Testing is not gatekeeping, right? You're not going to catch everything. And so how do you... And it allows them to do that. And I think it's okay. But then there are times, as we've seen today, where Riverside suddenly went down just before the recording, where it's like, ⁓ yeah. Sometimes it doesn't work out. well, and AWS, sometimes it's down to everything. mean, we live in a world that's run on the internet. Sometimes things are down. Yeah, all kind of, as I've told people before, some of my juniors, networks are more down than they're up. It's just by accident that we always have everything working because we have so much redundancy put into place. And I think there's a lot that people can learn. It's like, you know, how How can I add redundancy to many other things? Which then leads me on to kind of one of my questions with long waffle. How are you, and like especially in the age of AI where people are moving super fast, Like agile made us fast, now we're super fast. How are you kind of guiding people to modern, air quotes modern, ⁓ of kind of Being able to try new things without having compliance nightmares, you've worked for large companies and really important companies where compliance can be really important for them. How have you walked that tightrope? So I have an example here that I'm almost embarrassed to give. So the last product I worked on at Microsoft, is, and I left Microsoft nine years ago, and this is a product that when I, it was in beta, and I'll get to the punchline in a minute, when I left Microsoft nine years ago, this product was in beta, and the product that shipped then was, would say massively higher quality than the product that we use today. And I'll talk about that product. That product is Microsoft Teams. Teams was interesting, because I, ran all of the infrastructure delivery pipelines, everything from the developer desktop to the customer desktop. And the product at that time, and I don't know if it still does today, it used more open source software than any other product at Microsoft other than Yammer. Massive amount. was a React, no, it was originally Angular on Node, and massive amount of open source. Now Microsoft had a typical process, compliance of open source product needed regular reviews from security and needed from security and ⁓ different parts of compliance privacy. And also ⁓ it was this time with Microsoft other than things like things weren't shipping often the customer facing like like things that ran on a desktop weren't shipping often. Of course the services like Bing were shipping multiple times a day but that was all on the web. there was actually at the time a mandatory security review for every release done by Microsoft, which meant that I had to meet with security every Friday morning and they would grill me with questions like what's changed here and like they were trying to figure it out how also to, I'm not sure if I asked you question, I haven't told a story anyway. How do we, like we don't know how to review a product every week. So I took a bunch of time to make sure that You know, my prep for the week was, and I wrote tools for this and I probably have AI help me today, figure out what changed. And there was, of course, things we could add to ⁓ code, know, code review, PR check-ins, figure out what things potentially get flagged if we add a new open source. every Friday I would come into that meeting with them. said, here's the new open source we added, if any. Here are the new features we added and what, and here's the static analysis user, here's the security reports. Here's what we've done. ⁓ It was hard at first, because they didn't know how to do it, and they would have more questions than I had answers for. But we got used to it. So going back to your question, I think you just. It's answers part of it. ⁓ I got lost in the story here, but you can't just put your hands up in the air and give up. And you also have to understand where the other side is coming from in compliance. They're doing this stuff for a reason. They're not trying to be a gatekeeper. They're trying to keep ⁓ massive loss security breaches or the like from happening. They're doing something very important. ⁓ So the trick is just like anything else in software, and this is a very popular Weinberg quotes that I'll paraphrase because he's paraphrased himself is in technology eventually it's always a people problem. And that's the thing with AI. If I bounce around over here, it helps people write code faster. Writing code has never been the problem. Writing code is so easy compared to everything else we have to do in software. So freaking easy. So anything you're trying to do with experiments. or with moving faster. And that was a once a week meeting. And I'd say, here's the thing, we've already shipped this week, because the backend services for teams were already shipping 10, 11, 12 times a week. So eventually just came down to a people problem. And that's what I took care of. I met them where they were, figured out what they wanted. I didn't try and steamroll them and tell them, Lord, we know what we're doing. Leave us alone. You don't know how to evaluate this. I didn't play that game. nor did I say, OK, we'll do everything you want and I will spend half of my working week making sure compliance is all set up. We had respectful conversations so we could figure out a compromise that worked. And they were super happy with that, and we were super happy with that. And by the time I left, that weekly security meeting had turned into an email or a Teams message wherever it wasn't going to get lost. Yeah. I think what you've said there is really important. ⁓ Anecdotally, the open source projects generally tend to be good at thinking about these things because other companies would have thought about all the compliance problems and gone, hey, let me fix those compliance problems in your project ⁓ along the way. ⁓ Except, unfortunately, I don't know if you saw the news today, Axios had a ⁓ massive security breach in their NPM package, which created a huge supply chain attack. massive thing. I feel sorry for anyone. Yeah, I feel sorry for anyone who's caught in the blast radius. It installed a crypto miner onto your machine. nice. Well, those happen. If you've in software long enough, that's the thing done the most. Someone gets into your AWS or GCP, et cetera, account, they're going to install a crypto miner. 100%. That's first thing that happens. Awesome. I think it would be a miss for me not to mention AI because everyone's talking about it. We talked about it a little bit. We can go on though. One of the things that I've, I recently wrote about this and you're a prolific writer, that creating codes, the easy part, right? Everyone's been doing it and I think it's getting a lot worse. The thing that I wrote about is that if you're getting AI to write all these tests, how do you know they're actually valuable? To me, the value in quality is feedback loops. How quick are feedback loops? The value in it. How have you been... Because I read about you've been using AI to pair and things like that. How have you been kind of getting it to do those things where you're like, actually, I don't care about this, but this is actually valuable? Like, how have you been training it? Well, I think this is where the industry is figuring stuff out. the generative AI stuff we have, that's my collaborator. I don't let it do anything important for me, but I bounce ideas off of. In fact, just last night, I said, hey, I've read this book and this book and this other. I like this one and this one. Give me five book recommendations just for the hell of it. And it gave me a good one. It was great. So I use Gen.ai a lot for things like that. I use it for ⁓ summarizing job recs, just things that, like things like that is good at. I don't use it for decisions. Agentic.ai ⁓ trained on a much more specific set of information. ⁓ I've had a lot better luck with just in playing around with it. I'm not doing any production testing right now, but in getting it to do what I want and getting it to be accurate. ⁓ Remember, AI today is not very deterministic. just does what you ask it. ⁓ It can hallucinate depending on how it's trained. I saw a post on LinkedIn this morning. What if I get my agentic AI to do a bunch of testing for me and it lies to me and tells me test passed and they didn't? Well, it could. And we've heard, we've seen stories of AI doing that, of AI lying. So look, all my tests passed and then you go, no, they didn't. I think we trust but verify, but you're not. You're not counting on, like what AI can test really well is that functional correctness. Is this doing what, especially on endpoints, it can create tests for that. It's wonderful. AI is great. Give me unit tests that create 100 % code coverage. It'll do that. And that's great. People go, oh my gosh, my code is so completely well tested. Again, that's just functional correctness. That's on the dev side. So all that stuff, I trust AI and tools to do well enough for me. Functional correctness, I think we can get. It's not 100 % there, 98 % of the way there, which is better than we've ever had before. That's great. Quality is a lot more than functional correctness. AI can help a little bit with that. And I played a little bit with SmartBear's tools on this. I don't want to plug them too much in this podcast, but just say I use their tools because let me try them out. I created some web pages that had some bugs and it found them. I thought, OK, cool. There's some hope here. And we're just at the infancy there and tools like that and their competitors are going to grow so much that I think there are classes of bugs that AI can help find for us. we are so far away from taking an agent and saying, test this website and help me make sure it's bug free. We are so, so far away from that, if ever. Yeah, because a bug isn't I mean, traditionally, again, going back to functional correctness. ⁓ when I click this value, this doesn't change whatever. Am I is does this software solve a customer problem in a way that's intuitive and easy to use? And so much of software today, including popular software, does not do that. And that's where I think we need the human in there. I can help. I can. Here's the fun part. AI is going to help us get past all the things we used to worry about in quality, functional correctness, it do what I tell it to, is it performant, are there security issues? ⁓ It can find the vast majority of those things. And think of what happens if, again, AI is not taking testers away, it's automating a lot of the tasks that are somewhat menial so that testers and developers and UX and product can start figuring out. can we build software in a way that helps customers solve their problem more easily? You can look at Microsoft are great examples there. Photoshop's a great example of super powerful software does anything you want to, but man, the learning curve on that is ridiculous. I've had music software I've used in the past, the same thing. It's like, there's a, go ahead and give the name I used. have a, I know if you know this, I have a music composition degree. Used to write a lot of music. Not as much anymore. I use a product called Finale. which is wonderful. My license has expired a long time ago. It's a great piece of software, but every time I sat down to use it, I had to relearn it. And that's not good quality software. It's highly functional software that did everything I needed it to do. But to me, quality software is easy and intuitive to use for someone, for the primary audience, should have been me. Yeah. I like to describe Jira and Bugzilla in the same way. It's designed for engineers. But like every time I want to like, I need to find this bit of information three hours later reading documentation, trying to string together queries to get what I need. And you're like, there must be a better way. But no one's ever thought of this, right? Yeah. And I'm hoping in software we find the time to get to these. And let me just add one more little rant while we're here is we're seeing a lot of layoffs supposedly due to AI. ⁓ But a lot of times it's companies who are freeing up budget to invest more in AI. I think that there are plenty of improvements to make the software that require human people that aren't being made today. And I don't think that we've by any means created solutions for all of the problems that exist in mankind. We still need to create software for those things as well. once the economy, the worldwide economy kind of gets back on track a little bit, maybe not to massive COVID hiring levels, but There is so much need for problem solving. I'll work back. So many problems need to be solved. Software is a great solution to do that. what I see a lot of companies doing is investing in making the products they're already making versus solving the new problems that haven't been solved yet. So I think it'll turn around at some point. I'm still far from my soapbox. looking like I'm like eight feet above David right now looking down. I'm going to step down. No, the thing there is that like what I've said to people and like it's a huge unknown where companies are going. like when Anthropic is still hiring software engineers while saying, look, we're 100 % of our code is written by AI nowadays. it's not because they need someone to write code, it's that they need someone's creativity, as you put, or imagination to be able to solve the real problems. I like you. think some companies have over arched on kind of the layoffs. And hopefully it'll rebalance over time. ⁓ Awesome. So we're going to head into what I like as the quick fire out. ⁓ So as you can tell, I'm really bad at short answers, so I'll do my best. Well, it's the where this came from was originally I would want to ask people these questions. And it was so that I didn't get involved in waffle afterwards. Right. It's like the whole point is ideally we get these nice short answers and we have a bit of fun while we're doing it. I will do my best. Awesome. ⁓ Favorite testing tool you've ever used? my brain doesn't count. ⁓ My favorite testing tool is a debugger. Any debugger, because I can change values in there. can see what I can get those what happens scenarios right away. Any debugger. System debugger, app debugger, any debugger. Awesome. We talked about books earlier. ⁓ Three books that you would recommend to people to read in 2026? Zen and the Art of Motorcycle Maintenance by Piercig, ⁓ Treatise on Quality. ⁓ Leadership on the Line, book about adaptive leadership by Ronald Heffetz and others. And ⁓ Focalt's Pendulum by Umberto Eco. It's ⁓ fiction story. Lots of it's ⁓ based loosely on history, lots of it's like a really it's like the intellectual version of a Dan Brown novel. ⁓ okay. I'm not gonna have to read those. Awesome. Most overrated testing buzzword in the last decade. checking. ⁓ OK. I think you and I are good friends then. I'll leave it at that. Yeah. What's the most underrated skill that a tester has today? We talked about some of them. That they have or they need to have? going to hedge there. Either. don't Systems thinking. Cool. If you went in software engineering tech space, what would you be doing now? I'd be a school teacher. Awesome. I taught music for four years in public schools. I'd probably still be doing it. I fell back into tech because the paperwork and red tape to get back into teaching after I went to grad school was too much. If it were easier to get back into teaching, I'd probably still be doing that. Awesome. That's so cool. ⁓ My wife's ⁓ a professional violinist for the local orchestra. She's a tutti violin for seconds. so my kids love music. My eldest just passed his AVRSM grade eight piano. And that's his second instrument, grade eight. And he's only 15. he like music just comes to him naturally. I can't play any instruments. I'm the love item for the music world in my family. I can clap. I can sing badly. Things like that. Who is one person in the testing community that you think people should be following? Lisa Crispin. Okay, because Lisa and Janet do so much together. I'm going to say Lisa Christman and Janet Gregory. I like that answer. They're both amazing humans. have all the time in the world for them. Alan, this has been fantastic. I really appreciate all the time and effort that you've put into joining me today. I really appreciate it. ⁓ To our listeners, ⁓ where can they learn more from you? I know you're writing daily, where can they go find all of this? I don't know if I'm writing daily. I've been writing once or more times a week at angryweasel.substack.com. That's probably the best way to track me down. I'm on LinkedIn as well. You can find me there. But I write a lot about leadership and sometimes about testing your AI on angryweasel.substack.com. Awesome. And to everyone listening, please make sure that you press the follow or subscribe on whatever platform you've listened or watched us today. really appreciate it and hope to see you next time. Thank you. All right. Thank you. you