speaker-0: all about quality. It was all about working with the customer and delivering exactly what the customer wants and needs. And of course the very early books on extreme programming didn't really mention testers. They were all about testing. We really want you. It's like okay. So I started reading the book and it's a book about testing. If it's not what the customer wants, you haven't wasted a lot of time building it. And I don't know why that is such a hard concept to get across to teams. But our brains cannot handle more than like six priorities. Yeah, we can think about it's like when you turn on your TV now, there's so many potential channels, even if you're just in Netflix or someplace. So focus on six attributes of quality, for example, what's more important? Performance?
speaker-1: Welcome back to Browser Sack Talks, conversations that turn testing pain points into playbook. I'm your host David, and today we're joined by a true pioneer in the testing world. She's literally written books on agile testing, several of them, and has spent decades showing teams what to do. Welcome Lisa Crispin. Lisa, please introduce yourself.
speaker-0: Well, thank you, David. It's an honor to be here. And I really appreciate y'all's podcast and everything you do for the software community. Honestly, we really we really like the vendors that take that to the community to heart. and thank you for your kind words. I I can't t say anything I've done without mentioning my co author and partner in crime, Janet Gregory. We wrote all those books together and worked together really for more than the past twenty-five years, not at the same job. But different jobs, sharing our experiences. So I'm a tester by trade. I've mostly worked on teams, cross functional teams, building awesome products together, making our customers happy and enjoying our work. And the last few years I've moved into doing a bit of consulting and training and things like that. And I'm based in Northwest Vermont, which is about in the USA, but we're two hours south of Montreal by car. And I live on a little farm with three donkeys, four cats, and a husband, and lots of wildlife.
speaker-1: You're famous for your donkeys. Everywhere I've seen photos of you, there's always you and at least one of your donkeys.
speaker-0: look better in a picture with a donkey in it, that's for sure.
speaker-1: No. So, Lisa, one of the things that I've always appreciated on your work, and I think that everyone who's always appreciated on your work, is you've always advocated for kind of these whole team approaches and kind of getting to other people and how to do that. And you've kind of shaped a few engineering organizations and how they operate. So I want to start with that today and kind of see how you've done this philosophy to everyone. So as one of the pioneers in agile testing, do you have you seen the perception of quality evolve from the early days of agile to DevOps and where we are now?
speaker-0: That's an interesting th question because what attracted me to extreme programming, which is the first agile set of practices and principles that that I learned about was that it was all about quality. It was all about working with the customer and delivering exactly what the customer wants and needs and enjoying ourselves while we do it. And of course, the very early books on extreme programming didn't really mention testers. They were all about testing. So testers we had to kinda elbow our way in. But I find that DevOps is pretty much the same way. I remember back in I guess it was about twenty ten when Jez Humble and Dave Farley wrote their book, Continuous Delivery, which really popularized that idea, which my team had already been doing, they asked me to be a technical reviewer on that book. And I said, well, gosh, I mean, although I work on the pipelines and I I work closely with our operations guy, it's not my area expertise. I shouldn't be a technical editor. And they said, no, no. We really want you. And it's like, okay. So I started reading the book and it's a book about testing. So DevOps is really about testing too. And And and you even I mean, we realize now DevOps is just software development. This is all just good software development. And for example, Google's research group, they called themselves the DevOps and Research Assessment because they did the survey every year. and last I think it was last year, they said, you know, why do we call this the DevOps thing? 'Cause it's just software. So now they just go by Dora. They don't it's just the the letters. They don't use the term DevOps anymore. so It's all about just doing the best job that we can do.
speaker-1: Yeah. So the book you mentioned continues to the read. I think it's one of those books, similar to some of the books you've written, Ken Beck's written, that kind of just seemed to, as technology changes and all of that, the book still stays incredibly relevant. And I find it always amazing because I recommend that book when I talk about these things. And so, because it also shows like some of the hurdles that people are going to hit and how they can deal with it. What is kind of the biggest hurdles that you've seen with like through your consultancy, kind of your work that you kind of see people hitting you like, I've seen this before. Let me get you over it. It's, not going to be so scary.
speaker-0: Well, I think f teams really have I mean, I think we probably see this even today, that teams have a hard time getting into the concept of continuous integration and working in those small batches. And the biggest mistake I see that I think all software practitioners see is trying to deliver in big batches, which AI makes it even worse because then you're generating huge amounts of code at once. But But learning how to cut that down and make these tiny little commits and g kick it off your pipeline, it it doesn't matter like just put one test in there just to get started. Have one automated regression test in there. and then build from there. Take these little baby steps. And the other thing, of course, is that when we have more siloed people, the people writing the code tend to treat the testers as their safety net. So, you know, if you're walking on a high wire and there's a net under you, you don't have to be as good as you do as there's no safety net. So they can be pretty complacent about it. And and honestly, a lot of times it's a more of a management problem. Management's like, write code, get that code written, and they don't even allow developers, they don't feel empowered to do that testing. And so when I've worked in in organizations where Testing skills are part of what the developers need to go up their career ladder. They're happy to test. They want good quality. But when their the whip is cracked and, you know, get that code written, somebody else gonna test it. Of course they're gonna just crank out code or let AI crank out code, as the case may be.
speaker-1: Yeah, so we will get to the AI point. Yeah, exactly. But the interesting thing that you said there was like when people are kind of under the web, so to say, is that like, one of the things that I always struggle with when kind of managing engineers and things like that, is that I do, you know, if I have to crack the web, I have to crack the web because there's kind of normally a real reason for it. But then they go, you know, I don't have time to test and like for me as a manager, go, well, how do I know that you're actually doing your job? How do I manage you in that way? And I always find that kind of a weak excuse. Is that something you agree with?
speaker-0: it can be, but I mean I've worked in you know, and I of course most of the teams I've worked in, the developers were empowered to test. But what I've seen in organizations where they're not, I think it is more of a I mean it could it it depending on the person, it could either be, ooh, I don't have to worry about testing 'cause that's not part not my job. And other people who feel like, well I do want to I don't you know, I don't want to deliver bad code, but I I'm told this is not my job. And so I don't want to get in trouble. Right. I think that people who want to do a really good job are probably just gonna go try to find another company to work for. But of course that's harder these days. But but yeah, I mean I just think it's a when people go through university here at least, they don't get courses in testing. You know? Maybe they get a unit test course if they're lucky. So it's just not it's kind of not in the wheelhouse.
speaker-1: Yeah, the only one that's ever done a kind of a testing degree is James. Worked at Microsoft for years. Worked at Google. Really famous.
speaker-0: What do mean? Yeah.
speaker-1: I can't think of his surname. he was one of those people. James Wittaker. That's it.
speaker-0: There you go.
speaker-1: Yeah, James Wittaker was really good and he advocated for that and kind of got people. thoughts on doing things. He's no longer in the tech industry, but his work still lives on. So if people want to look him up, I do recommend reading some of the things that he's got out there. so carrying on this whole team quality and kind of agile evolution, one of the things that I see a lot of, like, he's still doing the rounds. I'm not a big fan of the name, but I can't think of a better name because I'm not very good at thinking of names, is the way people go, we need to just shift everything left. What does shift left mean to you? Because it changes depending on company. And how do people actually do it in a meaningful practice beyond just going, just write more unit tests?
speaker-0: Well, yeah, I don't like the term either because as Janet pointed out to me years ago, it makes it sound like software development's linear and it's not. It's a it's a loop, infinite loop. But if we look at say the DevOps loop that got popularized, by the way, I've never been able to determine who came up with the DevOps loop. Nobody admits to it. But you know, Janet and I adapted that into our holistic testing loop because we have all these stages we go through. There's no beginning, no end. But You know, usually the business brings an idea. They want to they want to create a new capability for customers or whatever. And it's really important. any of us who have been customers in the past and wanted software written for us know it's hard. You don't know exactly what you want. And you probably want the sun, the moon and the stars, and you really only needed the sun. and there's so much waste in software development, right? I think you know, the motto do less is a is a good one to live by. I'm trying to think who says that. But but it's really important to create only what the customer needs and only what will benefit them and the business. And and zoom in on that. What's most valuable here? And also what are the risks? I see I've seen so so many teams since I've been consulting That they're at they're agile teams. They're doing continuous integration. They're doing continuous delivery. They're even doing test driven development. And they get those requirements from the product people and that's what they do. They might ask questions to clarify the requirements, but they don't push back. They don't say, Well, there's a danger here if we do it this, you know, if we deliver this, these bad things could happen. You know, or hmm, this is really hard. We c we'd have a hard time automating any tests for this. And it's quite high impact if it was to happen in production. How do you want to deal with that? Maybe we don't even need that. And to have those conversations with the stakeholders, with the designers, with the operations people, everybody needs to be talking about this stuff. So that's what ShiftLuff is to me, is to spend that time. and if we're spending all of our time, unfortunately. still happens. I think even now, manually testing stuff after it's been written, we're not gonna have time to do that really important work. And we're gonna be testing code that doesn't even deliver what the customers wanted in the first place. So that's what's really important to have those effective conversations.
speaker-1: Yeah, and I think that that leads really nicely into my next question, which is around kind of, you know, streamlining pipelines. as I said, we'll get into the AI side of things, but kind of AI is generating loads of code, loads of tests. Everyone's just going, we'll just throw it in our pipeline. We'll see us. And pipelines are growing exponentially, I think. I saw something at from out of GitHub where GitHub actions over the last two years is kind of... They need three times the amount of infrastructure because of things of going in a hockey puck, a hockey stick shape. And I was like, wow, okay. And that's partly why GitHub's really been struggling the last few months with uptime. So how do you help teams shorten feedback loops Go for like you said risk-based stuff. How do you teach them to think about risk-based testing? Either in automation, in manual or things like that so that they can get to where you go, actually, we don't need this feature.
speaker-0: you know, I just think it starts with taking the new feature that the business wants and s slicing that into small chunks. First of all, eliminating all the waste. Maybe things are too risky or maybe they're just not valuable enough to the customer and we wanna, you know, we wanna start with that minimum viable piece or that l learning slice. So is it what the customers want? So certainly best to Start it with some thin end to end slice that shows what it capability is and then get feedback on it on it from the customer. So that ability to slice things down into a a reasonable amount. And then if it's not what the customer wants, you haven't wasted a lot of time building it. And I don't know why that is such a hard concept to get across to teams, but but it is. and yeah, just Thinking about the risk and and once we prioritize, I mean we need to really narrow it down. As as humans, our brains cannot handle more than like six priorities. You know, we can think about it's like when you turn on your TV now, there's so many potential channels, even if you're just in Netflix or someplace. You're gonna you could spend hours just browsing through it. If it only gave you six choices, you ch you decide quickly. So focus on six attributes of quality, for example, what's more important? Performance, functionality, security? installability, reliability, resilience. I mean there's lots of things that could be. So prioritize those things and then prioritize the risk. What are the six most important risks that would impact the product, impact the business, impact the customer? Now let's think how will we how will we manage those risks? There's so many ways to manage those risks. We could either test for them, we could try to prevent them, we could just agree we're going to watch for this in production and we'll be ready to respond to it. So there's lots of ways to do that. but it again it needs to be thought of in those planning stages and we don't want, you know, we're agile, we don't want big upfront design. So that's why we want to do it. W we definitely wanna look at the big picture of a feature. But then when we want to dive into the individual, like the first thin slice, then really focus in there, what's important. And then do we have you know, if we're doing something like behavior development, we're using those examples to turn it a test that got our coding. And we may end up with a lot of automated tests. We don't have to keep all those in our regression suite. We can identify the ones, what are the things that absolutely have to work? And your business people can usually tell you that. And then keep those regression tests so that you do get the faster feedback. You can manage those better. And and you've still got the other ones if you need So
speaker-1: Yeah, think that's really important. think giving people the agency, I think is the best way to describe it. Giving people the agency to go, we don't need this many tests. It becomes really important. And I think even more important in the age of AI. because it's like people just go, I've generated code. Hey, could you generate me some tests? And it's like, yeah, sure. Here's like all the permutations. You're like, okay, I don't really need all the permutations. I just need the most important, the highest risk and then go from there. I'm seeing a lot of people just generating loads of tests and going, yeah, this is good. as you said, earlier you said you wanted a good safety net and they think that's a good safety net. But a good safety net is one that catches you quickly, not like when you're nearly at the ground before you hit it. So let's, I want to move on to AI, continuous delivery and future testing and kind of how all of that works because I think it's something that has to be talked about and there are good things, bad things. And so hopefully we can go through all of that.
speaker-0: I'll do my best, but I mean disclaimer of friend, I have not had the opportunity to be on a team building something and using AI tools. So I'm just learning it by getting some training, doing workshops, watching what other people are doing, reading a lot, which is different than doing it in real life. But I'm talking to a lot of people doing it in real life. So
speaker-1: So one... Who was I speaking to? I think I was speaking to Alan Page. And he was in a previous podcast and he was saying about how a lot of AI nowadays and the emergence of Agile are literally all the same problems. And his excuse, like I said, was people in QA would go, If we are moving this to developers for testing, why do they need me? Or if they're doing this, why do we need QA? And there's a lot of like that. And I think in the age of AI, we need more professionals who understand how to test than fewer.
speaker-0: Mm-hmm. Yeah, I mean it's it's it and the great thing is, well, I don't know where you're going with your question, but the great thing is to me that the AI tools give us more capability to collaborate. As a I feel as a tester, I have a lot better chance to get a developer to pair with me if I say, Well, we're gonna use this cool AI assisted tool to help us generate our test automation. And it's gonna do the grunt work, but what we get to do is just think of the ideas. What do we think is important? What do we want that test to do? What things do we not want the test to do? Create those guidelines and and skills for the for the AI agents. And and I think we can get a lot more people working together with that than I've got this capture playback UI tool to create tests. You wanna do that with me? Mm-mm. I mean every team I worked on over the decades. They were happy to do unit level testing, API level testing, the developers, yeah, that's good, that's fine. Now we gotta do the UI level test. no, you do that. With the older technology.
speaker-1: I do think it's like... One of the things you've just said there to me really reinforces, at least to me, how important QA professionals are, right? Because they understand different things very differently to how developers do it, right? UI automation is an incredible skill in itself, right? And I will come back to our original question, but I do think it's really... really important that I think people realize how it is because it's not just, I'm going to write 100 Selenium playwright puppeteer test, whatever. Because these automation people are good at understanding the system and understanding the entire stack and hopefully trying to manage it to be not flaky, which I think is a skill in itself. and working across multiple browsers. Yeah. So back to my original question. No, it's really good because it still fits in perfectly. With what you're playing with, what you've been speaking to people, you've kind of answered half of my question, which was like, I was going to ask you, where do you see AI providing genuine value for testing teams? And you said it helps them create their tests. But where do you, like have you seen from other reading, playing with it, whatever? It's just hype and not actually doing meaningful work.
speaker-0: The people I've talked to that have had the most experience in, I mean, I know people whose teams have been doing this. They've been AI first for eight years. You know, it's not new to them. And what they the value they've discovered is it's just like taught test automation was at first. Everybody's like, no, we don't need testers, we have automated test. It does this work to free us up to do that work of discovery and helping the stakeholders understand what they want and what they need and what they don't need. Because that's so often nobody has time for that. Well now there's no reason we we're not over there, my God, the CI failed again. We had a flaky test. They're not spending time doing that. They're having a time to sit less with the business stakeholders and say, Well let's do a little mind map here of this feature and let's think of all the ways we that it could work and What risk could it have and how could we implement it? You know, we have time for those conversations where we didn't before. And to me, that's the that's the point. That's the point of having these tools.
speaker-1: Yeah, I wholeheartedly agree with that. And one of the things, and it was true 16, 20 years ago when test automation was coming up, and it's true today, that test automation only tells you a very small amount of what's happening. And AI is always going to give you test automation. It's not going to give you as you said, the imagination to like think through different things in different ways, things that make humans amazing creatures really, right? That imagination. And I think, think Marit, and it sounds like Marit was kind of saying something to what you and Janet were saying is that like, if you have a circle, you can kind of have like, have your automation helped with AI, because AI helps you imagine things better. And then you can play with like exploratory testing. And then you loop all the way back to kind of using your imagination with your coding pair.
speaker-0: Definitely. I I mean I think there's a there's a bit of a danger because I see I see some people it's like, well, I'm kind of pairing now with this, you know, AI, this gen AI LLM that's chatting with me and and responding to me. It feels like you're working with somebody, which is which is good. I mean that that can certainly help us work better. But we can't ignore talking to the other humans too. So that's the tr that's a trap I see that people really get into the tools so much. That they forget that the no, this just should be freeing my time up to talk to the humans more. use the AI tools to help us, but we can be more creative, more innovative. We can and the other thing is it allows really fast experiments. It's like, we want to build this web app to do this thing. You can quickly, anybody can quickly create a prototype, get that feedback. Because you know, using something with your hands, that's how you really know what you want. And so let's try let's try having it look this way. Mm, that's not right. But you do that together. You've got you've got your designers, your business stakeholders, your developers, maybe even your operations people to to say, you know, how would we monitor this in production, that kind of thing. Working together and getting being able to do this really fast. Nobody spending ages in a work session because we can get through it so fast and have really good results.
speaker-1: Yeah, definitely. the next thing I wanted to bring up, think it segues really nicely, is talking about continuous deployment speed and how with... You've got your automated tests. We've talked to that a lot, but I also think... To me personally, still think exploratory testing has value, even with AI. And I've seen a few people using AI to like, I'm thinking of testing it this way. Do you think this is going to be high risk, low risk? And then using their imagination, just like we were saying about pairing. But it's just helping them feel a bit more confident. How do you have you seen people trying to balance that kind of continuous deployment and exploratory testing?
speaker-0: Well, I mean, we've got the release strategies to give us the time to do exploratory testing. So, you know, we can we can keep that feature flag turned off or only release to some small percentage of people. We can still deploy to production and keep doing exploratory testing. So I mean the the that's given us so much freedom having that technology that lets us put things in production and decide who gets to see it. And maybe only we see it and and test it out and keep keep working on that feature. So I think I think that's the key of adopting and but and it and also requires a continued conversation. What's what is our best way to do this? What do we what technology do we want to use to manage what users see and let us have the time to do any kind of human centric testing. Maybe we want to do extra accessibility testing that can be automated. Or maybe we want to do, you know, some special security testing before we really turn it on. So there's a lot of I'm guessing that maybe even in this AI age there's maybe even more things we want to do to feel confident in that code before we spring it on the customers. And of course we have the ability to roll it back if it doesn't do what we want. But depending on what business domain you in you're in, you maybe can't afford to make a mistake. So you need that time to To explore. And you know, yeah, that I think that AI tools can really help us think of scenarios because that's w always been our problem. Even with exploratory testing, we still have the unknown unknowns that we didn't expect in production. And that comes to the observability of you know, how can we make sure that we're gonna spot those problems really fast, hopefully before the customers even see them.
speaker-1: Yes, definitely. I'm a big advocate for observability. before we got the show going today, we were talking about Motocon. I'm going to be doing a talk about observability and testing at Motocon. And so how it's not that scary and how you can have your automated tests running. and have a nice kind of workflow through everything, then you can see how everything holds up and you go, OK. So from your browser test all the way through your system and then back again and how you can show it. So I do think, yeah, I do think it's becoming really important nowadays because you can't test everything. And some things, even if you test it, doesn't actually tell you there's high quality there. And I do think a lot of developers don't get that. I think a lot of testers don't get it either, right? And to me, it's always about the risk, right? And so one of the things that I did want to talk about, because I know it's something that you kind of worked in kind of the space for a long time, is around like remote and hybrid software teams. like those are becoming the norm. I know there's a big push from certain companies to return back to office, but there's a lot of companies who haven't done that. How can... Quality advocates maintain good, strong, shared culture of quality in that space now, kind of the remote space, the hybrid space, and anything in between.
speaker-0: Yeah, that's a really that's a really tough problem. And I think hybrid is even more tricky than remote, because if you've got those people physically together, they're gonna ignore the remote people. but I mean I've been working personally. Started working at least partly remotely, I don't know, back in two thousand nine or something like that. So way way before the pandemic. And and actually when I first started doing it on my team back then. We made a little telepresence device. So it had a camera and a laptop and it was on wheels. And so if I was working from home, I could use my telepresence device and say, Wheel me over to, you know, Janet over there. And so 'cause I want to ask her a question or I want to see what she's doing and it helped me hear the hallway conversations that maybe people would forget to include me. But That's how's how we approached it back then when, you know, maybe only one or two people were working remotely. But what I found can be really effective is you you know, just use the technology. So for example, the last place I worked full time, we used we used Slack really effectively. So we had Slack channels. We had, I don't know, maybe half a dozen teams. It wasn't a huge company. But
speaker-1: Okay.
speaker-0: each team had its own Slack channel, but we also had a tester Slack channel. So that the testers from different teams could talk. And I can't tell you how many things came up there because we talked to each other. And maybe others didn't. And of course, with Slack and Teams and other other technology like that, you can quickly start up a conversation. It's like, let's do a huddle or let's get on, let's get on a video call. It's so easy to to start that up. And then the other thing we did was because we were on doing ensemble programming there. So mob programming or ensemble programming. Yeah. And so we would we would have a channel where we posted a link to our Zoom call and who's in it. So these three people are working together today. And anybody who wants to join us or talk to us can just click the link and join us. So making it really accessible just like walking around an office and finding the person that you want. And that worked really, really well. And then if we needed somebody, we could go and look and where is this person? And go and say, Hey, can we borrow you? And then they have they join our video call. So those kind of things really help. And just the non work stuff. one of the first place I worked during the pandemic was a Portuguese company based in Lisbon. And so I joined at like six or seven in the morning my time, which was their lunchtime. And they're big on food in Portugal, I learned. yeah. And so They would make these beautiful lunches, like gourmet lunches, and then everybody would show what they're eating. And we you know, we would all eat together. I was eating breakfast, but we would all eat to lunch together. You didn't have to, you didn't have to join that call, but you could. And it and of course during the pandemic, you're seeing everybody's houses and cats and kids and
speaker-1: Yeah
speaker-0: which was maybe uncomfortable for some people, but it just helps you just get to know people a little better. i everybody had that food thing in common and and it could be it could be a lot of different interests or playing online games together. I've done a lot of that with my remote teams. Just having some fun together. Just like as if, you know, just like back in the day on my early software teams, let's all let's all go have a beer or let's go play racquetball or let's go play softball. you can still do fun things. And I think it's really important to build that personal connection because it's all about culture. It's all about everybody feeling That level of trust that even if we have a difference of opinion on how to implement something or how to test something, we can have that discussion and not take it personally because we know that though we're valued and we can feel safe to express opinions, point out problems. That's that's the prerequisite to success, right?
speaker-1: Definitely. So before we head into the quick fire round, I have one last question because you've had such great experience and been able to look ahead and help people with their careers. What do you think, over the next five, 10 years, because things are moving so fast, are core competencies? Do you think that traditional testers must develop to stay vital in the automated, AI-driven development workflows?
speaker-0: Well, clearly everybody needs to learn these AI tools and everybody seems to be able to learn them, right? Even the business people are cranking out prototypes and stuff, marketing people, whatever. But I think it's the communication. So we all have to keep speaking the same language. So, you know, Janet and I used to use the term technical awareness. Like you you may not be a coder, but you can learn how to read code and you can learn how to use the IDE so that you can sit down with a developer in person or remotely and your whatever IDE you're using, IntelliJ or JetBran, you know, whatever. Visual Studio, you can navigate around that well enough to understand what they're doing. And and so the same thing's true with any AI tools and stuff, cloud code, whatever, just being being familiar enough with those that you can have that conversations. And of course you want them to be able to talk testing with you, but they may or may not they may or may not do that. I don't know. we can certainly we can certainly encourage it. I mean I've always wherever I've worked, I've always done little workshops like let's have a little exploratory testing workshop or, you know, do have some fun, short half hour hour activity where people can try different testing things together. You know, let's try example mapping together, whatever it is. So still doing those kind of things. But yeah, it all it all comes down to communication skills, right? And and the other thing is just your attitude and mindset. So when I was hiring testers, I didn't look for specific skills. I didn't look for, they know how to make Selenium tests or they know how to do exploratory testing. I wanted to know that they're Very curious and eager to learn and they feel fine to ask questions and they're willing to just try anything. And I I can teach people the skills they need to know, or I can help them learn the skills they need to know, but I can't, it's harder to instill that kind of mindset with people. And so I would always pair with people, or sometimes if we could do it without overwhelming and try a little ensemble together to say, hey. Let's look at this UI page that we're working on, our team's working on right now. How would you go about testing this? And you know, feel free to ask any questions about it. and then see what questions they ask and see how fast they seem to pick things up. That's true no matter what technology we're using. Those kind of skills of eager to learn and able to learn, you know, quickly enough. and willing to just willing to try things out. Courage. 'Cause we all need courage.
speaker-1: I do think everyone needs courage and I think to all the managers out there, if you're wanting to help your teams the most, is kind of how do you give your teams the agency to feel courageous, I think is the thing for me as a manager. and I promise, not promise, but in my experience, if your teams have agency and they're feeling courageous, You don't really need to manage them that much because they just do amazing things.
speaker-0: Exactly. Exactly. You gotta hire hire the right people, hire good people and get out of their way.
speaker-1: Definitely. Awesome. So we're going to head into the quick fire round. This is where I ask you a few questions and the answers need to be fairly succinct. So I'll you like 30 seconds, 45 seconds to answer. But it's just kind of things that come off your mind when I ask the question and we'll go from there. Are you ready?
speaker-0: That's right as Oliver B.
speaker-1: favorite testing tool or concept that you've used across your career.
speaker-0: Are so many. but actually when I think about it, and I tell people this a lot, the favorite technique I ever learned to help me the most and help my teams the most testing is mind mapping. I learned it at a conference back in 2006. And I brought it back to my team and taught my team and taught our product owner, and I'm telling you. It's just done so much in terms of helping us think outside the box, which is so important. Do that lateral thinking, that creative thinking, creative problem solving, looking at risks, looking at what's important to customers, all those things. Having that thing you can do together, 'cause even on a virtual whiteboard, everybody can draw together and add nodes and go off on branches and ideas and it helps us have a conversation and we can use them as a test plan. We can use them for so many things. So That's by far the most I I plan my day with a mind map. You can just do so many things with it.
speaker-1: Wow, cool. What is one book every QA lead or software engineer should read in 2026?
speaker-0: There are so many books and really great ones coming out all the time. But I'm gonna go with a classic because l like you say, a lot of the books they don't get out of date. And I'm gonna go with well, just two books, Fearless Change and More Fearless Change by Linda Rising and Mary Lynn Manns. And they're patterns for helping us influence change or spark change in our organizations because we're all faced with that. Yeah. You know, we all say, the developers they're not they're not doing unit testing. How could we get them to do unit testing? Or the tool we're using is not right for us. How can we convince management that we need to go a different direction with that? Or our process needs changing, or we need to have a process retrospective. Whatever it is, I know every and everybody I know has always felt that frustration. And and sometimes feel like It's just hopeless I won't be able to change. But we all can be change agents and you have to try. And these little patterns are little things you can try quickly. And if it doesn't work, you go on to the next one. So for example, one of them is the elevator speech. Of course, this goes back to the days we're co-located, but if you got into the elevator with the CTO, have your 15 second speech prepared for the thing you want that person to think about. Yeah. Be ready and take the opportunity. Or, you know, simple things like find an ally, find somebody who thinks like you do. Now you can brainstorm together and maybe now you can go more allies and you can just get your initiative going that way. the other pattern that worked really well for me when I was on a co located team is do food. Because you can get anybody to come come to a meeting room and look at something if you provide, you know, brownies or cheese or something, pizza, whatever they want. so It's just a for me working in a you know, I've work gotten in organizations where I thought, well, they're they're agile, they're gonna do the thing and then realize, no, they're very dysfunctional. How can I en effect any change? And it gave me tools to try that. Now sometimes it doesn't you know, sometimes you try everything and it didn't work and then change your organization or change your organization, right? But I think f across the board, those books help everybody.
speaker-1: Awesome. What do you consider the most underhyped QA metric?
speaker-0: Hmm. Well, I'm a fan of Google's Dora Key metrics, which came out of many years of scientific research of what the teams that are high performing, that please their customers, that make their businesses profitable and that are happy, what practices do they do? And the metrics that I think that are that can really reflect, especially process quality, which you need process quality. to get product quality or things like how frequently do we deliver, what's our cycle time, how long from when we start something to when we finish, because that correlates with those small chunks, frequent delivery. those are those would be my two favorite ones. There are other ones that I think are good, but Perfect. To really focus us on doing one small thing at a time, doing it well.
speaker-1: What's the most underrated skill for testers today?
speaker-0: what I already talked about, the commu those communication skills and what Janet and I used we we cook and I think we got this from Isabel Evans actually is thinking skills. So some people say soft skills, some people say harder skills because they are harder. But being able to communicate and collaborate with people is so essential because we can't have that holistic approach with everybody on the team owning quality and working hard to build it in if we can't. communicate with each other. So Awesome. And yet nobody says people send their people to training on how to use this tool or that tool or that programming language. They don't ever send them to communication class.
speaker-1: is very true. Very, very true. If you weren't working in software testing or tech, what career path do think you would have pursued?
speaker-0: you know, like everybody, I accidentally got into this. when I was a child I wanted to well, I wanted to be an artist. and I wanted to be a writer, writer, R I T E R and I also wanted a ranch 'cause I I was horsey. Now I have donkeys, but I used to have horses. And so yeah, I wanted a ranch in the mountains where I could paint and write. Painting turns out not to be a skill that I have. I appreciate art. But written books, not the creative writing I had in mind. But I do live in the on a ranch. There's a a mountain right next right we can see outside our window it's a small mountain. It's not the ones we used to have in Colorado. And I can see the Adirondacks across the lake in New York from our property. So it's kind of the ch the dream. So I could have gone either way.
speaker-1: Awesome. And final question, what book, podcast or person has influenced your thinking the most recently?
speaker-0: Well, I have to see. I I still gotta go with Janet, although she's trying to be retired. I'm not an idea person. And Janet's always been the one to come up with the ideas and then I go try out and then try to share with everybody. And though she says she's actually she is the artist, so she has devoted most of her time to improving her painting skills. But she's still she's still on LinkedIn every day. She still points me to interesting articles and we still do a lot of writing and and podcast or video chats together. And she's still the person that always she sees it from that angle that I missed. And so it's hard not working with her as much as we used to, but I still cling to that bit of inspiration that she provides me.
speaker-1: amazing. This has been an amazing recording. I enjoyed every minute of it. Thank you so much for sharing your insights, your practicalities, deep history, everything. Thank you so much for joining me today.
speaker-0: Well, thank you. It gives me some more energy to go out and learn new things.
speaker-1: Awesome. If people wanted to see what you're doing, follow you, what is the best way for them to do that?
speaker-0: As far as social media, I'm mainly on LinkedIn, so you can find me there. Just look for my name and then LisaCrispin dot com is my website and it has links to our gents and my book website and our training website and things you can find all that there.
speaker-1: Amazing. And to everyone who's listened or watched, please don't forget to hit the Subscribe or Follow button for browser stack talks on your favorite platform so you can never miss an episode. And hopefully we will see you soon. Thank you all.
speaker-0: Thank you.
speaker-1: Welcome back to Browser Sack Talks, conversations that turn testing pain points into playbook. I'm your host David, and today we're joined by a true pioneer in the testing world. She's literally written books on agile testing, several of them, and has spent decades showing teams what to do. Welcome Lisa Crispin. Lisa, please introduce yourself.
speaker-0: Well, thank you, David. It's an honor to be here. And I really appreciate y'all's podcast and everything you do for the software community. Honestly, we really we really like the vendors that take that to the community to heart. and thank you for your kind words. I I can't t say anything I've done without mentioning my co author and partner in crime, Janet Gregory. We wrote all those books together and worked together really for more than the past twenty-five years, not at the same job. But different jobs, sharing our experiences. So I'm a tester by trade. I've mostly worked on teams, cross functional teams, building awesome products together, making our customers happy and enjoying our work. And the last few years I've moved into doing a bit of consulting and training and things like that. And I'm based in Northwest Vermont, which is about in the USA, but we're two hours south of Montreal by car. And I live on a little farm with three donkeys, four cats, and a husband, and lots of wildlife.
speaker-1: You're famous for your donkeys. Everywhere I've seen photos of you, there's always you and at least one of your donkeys.
speaker-0: look better in a picture with a donkey in it, that's for sure.
speaker-1: No. So, Lisa, one of the things that I've always appreciated on your work, and I think that everyone who's always appreciated on your work, is you've always advocated for kind of these whole team approaches and kind of getting to other people and how to do that. And you've kind of shaped a few engineering organizations and how they operate. So I want to start with that today and kind of see how you've done this philosophy to everyone. So as one of the pioneers in agile testing, do you have you seen the perception of quality evolve from the early days of agile to DevOps and where we are now?
speaker-0: That's an interesting th question because what attracted me to extreme programming, which is the first agile set of practices and principles that that I learned about was that it was all about quality. It was all about working with the customer and delivering exactly what the customer wants and needs and enjoying ourselves while we do it. And of course, the very early books on extreme programming didn't really mention testers. They were all about testing. So testers we had to kinda elbow our way in. But I find that DevOps is pretty much the same way. I remember back in I guess it was about twenty ten when Jez Humble and Dave Farley wrote their book, Continuous Delivery, which really popularized that idea, which my team had already been doing, they asked me to be a technical reviewer on that book. And I said, well, gosh, I mean, although I work on the pipelines and I I work closely with our operations guy, it's not my area expertise. I shouldn't be a technical editor. And they said, no, no. We really want you. And it's like, okay. So I started reading the book and it's a book about testing. So DevOps is really about testing too. And And and you even I mean, we realize now DevOps is just software development. This is all just good software development. And for example, Google's research group, they called themselves the DevOps and Research Assessment because they did the survey every year. and last I think it was last year, they said, you know, why do we call this the DevOps thing? 'Cause it's just software. So now they just go by Dora. They don't it's just the the letters. They don't use the term DevOps anymore. so It's all about just doing the best job that we can do.
speaker-1: Yeah. So the book you mentioned continues to the read. I think it's one of those books, similar to some of the books you've written, Ken Beck's written, that kind of just seemed to, as technology changes and all of that, the book still stays incredibly relevant. And I find it always amazing because I recommend that book when I talk about these things. And so, because it also shows like some of the hurdles that people are going to hit and how they can deal with it. What is kind of the biggest hurdles that you've seen with like through your consultancy, kind of your work that you kind of see people hitting you like, I've seen this before. Let me get you over it. It's, not going to be so scary.
speaker-0: Well, I think f teams really have I mean, I think we probably see this even today, that teams have a hard time getting into the concept of continuous integration and working in those small batches. And the biggest mistake I see that I think all software practitioners see is trying to deliver in big batches, which AI makes it even worse because then you're generating huge amounts of code at once. But But learning how to cut that down and make these tiny little commits and g kick it off your pipeline, it it doesn't matter like just put one test in there just to get started. Have one automated regression test in there. and then build from there. Take these little baby steps. And the other thing, of course, is that when we have more siloed people, the people writing the code tend to treat the testers as their safety net. So, you know, if you're walking on a high wire and there's a net under you, you don't have to be as good as you do as there's no safety net. So they can be pretty complacent about it. And and honestly, a lot of times it's a more of a management problem. Management's like, write code, get that code written, and they don't even allow developers, they don't feel empowered to do that testing. And so when I've worked in in organizations where Testing skills are part of what the developers need to go up their career ladder. They're happy to test. They want good quality. But when their the whip is cracked and, you know, get that code written, somebody else gonna test it. Of course they're gonna just crank out code or let AI crank out code, as the case may be.
speaker-1: Yeah, so we will get to the AI point. Yeah, exactly. But the interesting thing that you said there was like when people are kind of under the web, so to say, is that like, one of the things that I always struggle with when kind of managing engineers and things like that, is that I do, you know, if I have to crack the web, I have to crack the web because there's kind of normally a real reason for it. But then they go, you know, I don't have time to test and like for me as a manager, go, well, how do I know that you're actually doing your job? How do I manage you in that way? And I always find that kind of a weak excuse. Is that something you agree with?
speaker-0: it can be, but I mean I've worked in you know, and I of course most of the teams I've worked in, the developers were empowered to test. But what I've seen in organizations where they're not, I think it is more of a I mean it could it it depending on the person, it could either be, ooh, I don't have to worry about testing 'cause that's not part not my job. And other people who feel like, well I do want to I don't you know, I don't want to deliver bad code, but I I'm told this is not my job. And so I don't want to get in trouble. Right. I think that people who want to do a really good job are probably just gonna go try to find another company to work for. But of course that's harder these days. But but yeah, I mean I just think it's a when people go through university here at least, they don't get courses in testing. You know? Maybe they get a unit test course if they're lucky. So it's just not it's kind of not in the wheelhouse.
speaker-1: Yeah, the only one that's ever done a kind of a testing degree is James. Worked at Microsoft for years. Worked at Google. Really famous.
speaker-0: What do mean? Yeah.
speaker-1: I can't think of his surname. he was one of those people. James Wittaker. That's it.
speaker-0: There you go.
speaker-1: Yeah, James Wittaker was really good and he advocated for that and kind of got people. thoughts on doing things. He's no longer in the tech industry, but his work still lives on. So if people want to look him up, I do recommend reading some of the things that he's got out there. so carrying on this whole team quality and kind of agile evolution, one of the things that I see a lot of, like, he's still doing the rounds. I'm not a big fan of the name, but I can't think of a better name because I'm not very good at thinking of names, is the way people go, we need to just shift everything left. What does shift left mean to you? Because it changes depending on company. And how do people actually do it in a meaningful practice beyond just going, just write more unit tests?
speaker-0: Well, yeah, I don't like the term either because as Janet pointed out to me years ago, it makes it sound like software development's linear and it's not. It's a it's a loop, infinite loop. But if we look at say the DevOps loop that got popularized, by the way, I've never been able to determine who came up with the DevOps loop. Nobody admits to it. But you know, Janet and I adapted that into our holistic testing loop because we have all these stages we go through. There's no beginning, no end. But You know, usually the business brings an idea. They want to they want to create a new capability for customers or whatever. And it's really important. any of us who have been customers in the past and wanted software written for us know it's hard. You don't know exactly what you want. And you probably want the sun, the moon and the stars, and you really only needed the sun. and there's so much waste in software development, right? I think you know, the motto do less is a is a good one to live by. I'm trying to think who says that. But but it's really important to create only what the customer needs and only what will benefit them and the business. And and zoom in on that. What's most valuable here? And also what are the risks? I see I've seen so so many teams since I've been consulting That they're at they're agile teams. They're doing continuous integration. They're doing continuous delivery. They're even doing test driven development. And they get those requirements from the product people and that's what they do. They might ask questions to clarify the requirements, but they don't push back. They don't say, Well, there's a danger here if we do it this, you know, if we deliver this, these bad things could happen. You know, or hmm, this is really hard. We c we'd have a hard time automating any tests for this. And it's quite high impact if it was to happen in production. How do you want to deal with that? Maybe we don't even need that. And to have those conversations with the stakeholders, with the designers, with the operations people, everybody needs to be talking about this stuff. So that's what ShiftLuff is to me, is to spend that time. and if we're spending all of our time, unfortunately. still happens. I think even now, manually testing stuff after it's been written, we're not gonna have time to do that really important work. And we're gonna be testing code that doesn't even deliver what the customers wanted in the first place. So that's what's really important to have those effective conversations.
speaker-1: Yeah, and I think that that leads really nicely into my next question, which is around kind of, you know, streamlining pipelines. as I said, we'll get into the AI side of things, but kind of AI is generating loads of code, loads of tests. Everyone's just going, we'll just throw it in our pipeline. We'll see us. And pipelines are growing exponentially, I think. I saw something at from out of GitHub where GitHub actions over the last two years is kind of... They need three times the amount of infrastructure because of things of going in a hockey puck, a hockey stick shape. And I was like, wow, okay. And that's partly why GitHub's really been struggling the last few months with uptime. So how do you help teams shorten feedback loops Go for like you said risk-based stuff. How do you teach them to think about risk-based testing? Either in automation, in manual or things like that so that they can get to where you go, actually, we don't need this feature.
speaker-0: you know, I just think it starts with taking the new feature that the business wants and s slicing that into small chunks. First of all, eliminating all the waste. Maybe things are too risky or maybe they're just not valuable enough to the customer and we wanna, you know, we wanna start with that minimum viable piece or that l learning slice. So is it what the customers want? So certainly best to Start it with some thin end to end slice that shows what it capability is and then get feedback on it on it from the customer. So that ability to slice things down into a a reasonable amount. And then if it's not what the customer wants, you haven't wasted a lot of time building it. And I don't know why that is such a hard concept to get across to teams, but but it is. and yeah, just Thinking about the risk and and once we prioritize, I mean we need to really narrow it down. As as humans, our brains cannot handle more than like six priorities. You know, we can think about it's like when you turn on your TV now, there's so many potential channels, even if you're just in Netflix or someplace. You're gonna you could spend hours just browsing through it. If it only gave you six choices, you ch you decide quickly. So focus on six attributes of quality, for example, what's more important? Performance, functionality, security? installability, reliability, resilience. I mean there's lots of things that could be. So prioritize those things and then prioritize the risk. What are the six most important risks that would impact the product, impact the business, impact the customer? Now let's think how will we how will we manage those risks? There's so many ways to manage those risks. We could either test for them, we could try to prevent them, we could just agree we're going to watch for this in production and we'll be ready to respond to it. So there's lots of ways to do that. but it again it needs to be thought of in those planning stages and we don't want, you know, we're agile, we don't want big upfront design. So that's why we want to do it. W we definitely wanna look at the big picture of a feature. But then when we want to dive into the individual, like the first thin slice, then really focus in there, what's important. And then do we have you know, if we're doing something like behavior development, we're using those examples to turn it a test that got our coding. And we may end up with a lot of automated tests. We don't have to keep all those in our regression suite. We can identify the ones, what are the things that absolutely have to work? And your business people can usually tell you that. And then keep those regression tests so that you do get the faster feedback. You can manage those better. And and you've still got the other ones if you need So
speaker-1: Yeah, think that's really important. think giving people the agency, I think is the best way to describe it. Giving people the agency to go, we don't need this many tests. It becomes really important. And I think even more important in the age of AI. because it's like people just go, I've generated code. Hey, could you generate me some tests? And it's like, yeah, sure. Here's like all the permutations. You're like, okay, I don't really need all the permutations. I just need the most important, the highest risk and then go from there. I'm seeing a lot of people just generating loads of tests and going, yeah, this is good. as you said, earlier you said you wanted a good safety net and they think that's a good safety net. But a good safety net is one that catches you quickly, not like when you're nearly at the ground before you hit it. So let's, I want to move on to AI, continuous delivery and future testing and kind of how all of that works because I think it's something that has to be talked about and there are good things, bad things. And so hopefully we can go through all of that.
speaker-0: I'll do my best, but I mean disclaimer of friend, I have not had the opportunity to be on a team building something and using AI tools. So I'm just learning it by getting some training, doing workshops, watching what other people are doing, reading a lot, which is different than doing it in real life. But I'm talking to a lot of people doing it in real life. So
speaker-1: So one... Who was I speaking to? I think I was speaking to Alan Page. And he was in a previous podcast and he was saying about how a lot of AI nowadays and the emergence of Agile are literally all the same problems. And his excuse, like I said, was people in QA would go, If we are moving this to developers for testing, why do they need me? Or if they're doing this, why do we need QA? And there's a lot of like that. And I think in the age of AI, we need more professionals who understand how to test than fewer.
speaker-0: Mm-hmm. Yeah, I mean it's it's it and the great thing is, well, I don't know where you're going with your question, but the great thing is to me that the AI tools give us more capability to collaborate. As a I feel as a tester, I have a lot better chance to get a developer to pair with me if I say, Well, we're gonna use this cool AI assisted tool to help us generate our test automation. And it's gonna do the grunt work, but what we get to do is just think of the ideas. What do we think is important? What do we want that test to do? What things do we not want the test to do? Create those guidelines and and skills for the for the AI agents. And and I think we can get a lot more people working together with that than I've got this capture playback UI tool to create tests. You wanna do that with me? Mm-mm. I mean every team I worked on over the decades. They were happy to do unit level testing, API level testing, the developers, yeah, that's good, that's fine. Now we gotta do the UI level test. no, you do that. With the older technology.
speaker-1: I do think it's like... One of the things you've just said there to me really reinforces, at least to me, how important QA professionals are, right? Because they understand different things very differently to how developers do it, right? UI automation is an incredible skill in itself, right? And I will come back to our original question, but I do think it's really... really important that I think people realize how it is because it's not just, I'm going to write 100 Selenium playwright puppeteer test, whatever. Because these automation people are good at understanding the system and understanding the entire stack and hopefully trying to manage it to be not flaky, which I think is a skill in itself. and working across multiple browsers. Yeah. So back to my original question. No, it's really good because it still fits in perfectly. With what you're playing with, what you've been speaking to people, you've kind of answered half of my question, which was like, I was going to ask you, where do you see AI providing genuine value for testing teams? And you said it helps them create their tests. But where do you, like have you seen from other reading, playing with it, whatever? It's just hype and not actually doing meaningful work.
speaker-0: The people I've talked to that have had the most experience in, I mean, I know people whose teams have been doing this. They've been AI first for eight years. You know, it's not new to them. And what they the value they've discovered is it's just like taught test automation was at first. Everybody's like, no, we don't need testers, we have automated test. It does this work to free us up to do that work of discovery and helping the stakeholders understand what they want and what they need and what they don't need. Because that's so often nobody has time for that. Well now there's no reason we we're not over there, my God, the CI failed again. We had a flaky test. They're not spending time doing that. They're having a time to sit less with the business stakeholders and say, Well let's do a little mind map here of this feature and let's think of all the ways we that it could work and What risk could it have and how could we implement it? You know, we have time for those conversations where we didn't before. And to me, that's the that's the point. That's the point of having these tools.
speaker-1: Yeah, I wholeheartedly agree with that. And one of the things, and it was true 16, 20 years ago when test automation was coming up, and it's true today, that test automation only tells you a very small amount of what's happening. And AI is always going to give you test automation. It's not going to give you as you said, the imagination to like think through different things in different ways, things that make humans amazing creatures really, right? That imagination. And I think, think Marit, and it sounds like Marit was kind of saying something to what you and Janet were saying is that like, if you have a circle, you can kind of have like, have your automation helped with AI, because AI helps you imagine things better. And then you can play with like exploratory testing. And then you loop all the way back to kind of using your imagination with your coding pair.
speaker-0: Definitely. I I mean I think there's a there's a bit of a danger because I see I see some people it's like, well, I'm kind of pairing now with this, you know, AI, this gen AI LLM that's chatting with me and and responding to me. It feels like you're working with somebody, which is which is good. I mean that that can certainly help us work better. But we can't ignore talking to the other humans too. So that's the tr that's a trap I see that people really get into the tools so much. That they forget that the no, this just should be freeing my time up to talk to the humans more. use the AI tools to help us, but we can be more creative, more innovative. We can and the other thing is it allows really fast experiments. It's like, we want to build this web app to do this thing. You can quickly, anybody can quickly create a prototype, get that feedback. Because you know, using something with your hands, that's how you really know what you want. And so let's try let's try having it look this way. Mm, that's not right. But you do that together. You've got you've got your designers, your business stakeholders, your developers, maybe even your operations people to to say, you know, how would we monitor this in production, that kind of thing. Working together and getting being able to do this really fast. Nobody spending ages in a work session because we can get through it so fast and have really good results.
speaker-1: Yeah, definitely. the next thing I wanted to bring up, think it segues really nicely, is talking about continuous deployment speed and how with... You've got your automated tests. We've talked to that a lot, but I also think... To me personally, still think exploratory testing has value, even with AI. And I've seen a few people using AI to like, I'm thinking of testing it this way. Do you think this is going to be high risk, low risk? And then using their imagination, just like we were saying about pairing. But it's just helping them feel a bit more confident. How do you have you seen people trying to balance that kind of continuous deployment and exploratory testing?
speaker-0: Well, I mean, we've got the release strategies to give us the time to do exploratory testing. So, you know, we can we can keep that feature flag turned off or only release to some small percentage of people. We can still deploy to production and keep doing exploratory testing. So I mean the the that's given us so much freedom having that technology that lets us put things in production and decide who gets to see it. And maybe only we see it and and test it out and keep keep working on that feature. So I think I think that's the key of adopting and but and it and also requires a continued conversation. What's what is our best way to do this? What do we what technology do we want to use to manage what users see and let us have the time to do any kind of human centric testing. Maybe we want to do extra accessibility testing that can be automated. Or maybe we want to do, you know, some special security testing before we really turn it on. So there's a lot of I'm guessing that maybe even in this AI age there's maybe even more things we want to do to feel confident in that code before we spring it on the customers. And of course we have the ability to roll it back if it doesn't do what we want. But depending on what business domain you in you're in, you maybe can't afford to make a mistake. So you need that time to To explore. And you know, yeah, that I think that AI tools can really help us think of scenarios because that's w always been our problem. Even with exploratory testing, we still have the unknown unknowns that we didn't expect in production. And that comes to the observability of you know, how can we make sure that we're gonna spot those problems really fast, hopefully before the customers even see them.
speaker-1: Yes, definitely. I'm a big advocate for observability. before we got the show going today, we were talking about Motocon. I'm going to be doing a talk about observability and testing at Motocon. And so how it's not that scary and how you can have your automated tests running. and have a nice kind of workflow through everything, then you can see how everything holds up and you go, OK. So from your browser test all the way through your system and then back again and how you can show it. So I do think, yeah, I do think it's becoming really important nowadays because you can't test everything. And some things, even if you test it, doesn't actually tell you there's high quality there. And I do think a lot of developers don't get that. I think a lot of testers don't get it either, right? And to me, it's always about the risk, right? And so one of the things that I did want to talk about, because I know it's something that you kind of worked in kind of the space for a long time, is around like remote and hybrid software teams. like those are becoming the norm. I know there's a big push from certain companies to return back to office, but there's a lot of companies who haven't done that. How can... Quality advocates maintain good, strong, shared culture of quality in that space now, kind of the remote space, the hybrid space, and anything in between.
speaker-0: Yeah, that's a really that's a really tough problem. And I think hybrid is even more tricky than remote, because if you've got those people physically together, they're gonna ignore the remote people. but I mean I've been working personally. Started working at least partly remotely, I don't know, back in two thousand nine or something like that. So way way before the pandemic. And and actually when I first started doing it on my team back then. We made a little telepresence device. So it had a camera and a laptop and it was on wheels. And so if I was working from home, I could use my telepresence device and say, Wheel me over to, you know, Janet over there. And so 'cause I want to ask her a question or I want to see what she's doing and it helped me hear the hallway conversations that maybe people would forget to include me. But That's how's how we approached it back then when, you know, maybe only one or two people were working remotely. But what I found can be really effective is you you know, just use the technology. So for example, the last place I worked full time, we used we used Slack really effectively. So we had Slack channels. We had, I don't know, maybe half a dozen teams. It wasn't a huge company. But
speaker-1: Okay.
speaker-0: each team had its own Slack channel, but we also had a tester Slack channel. So that the testers from different teams could talk. And I can't tell you how many things came up there because we talked to each other. And maybe others didn't. And of course, with Slack and Teams and other other technology like that, you can quickly start up a conversation. It's like, let's do a huddle or let's get on, let's get on a video call. It's so easy to to start that up. And then the other thing we did was because we were on doing ensemble programming there. So mob programming or ensemble programming. Yeah. And so we would we would have a channel where we posted a link to our Zoom call and who's in it. So these three people are working together today. And anybody who wants to join us or talk to us can just click the link and join us. So making it really accessible just like walking around an office and finding the person that you want. And that worked really, really well. And then if we needed somebody, we could go and look and where is this person? And go and say, Hey, can we borrow you? And then they have they join our video call. So those kind of things really help. And just the non work stuff. one of the first place I worked during the pandemic was a Portuguese company based in Lisbon. And so I joined at like six or seven in the morning my time, which was their lunchtime. And they're big on food in Portugal, I learned. yeah. And so They would make these beautiful lunches, like gourmet lunches, and then everybody would show what they're eating. And we you know, we would all eat together. I was eating breakfast, but we would all eat to lunch together. You didn't have to, you didn't have to join that call, but you could. And it and of course during the pandemic, you're seeing everybody's houses and cats and kids and
speaker-1: Yeah
speaker-0: which was maybe uncomfortable for some people, but it just helps you just get to know people a little better. i everybody had that food thing in common and and it could be it could be a lot of different interests or playing online games together. I've done a lot of that with my remote teams. Just having some fun together. Just like as if, you know, just like back in the day on my early software teams, let's all let's all go have a beer or let's go play racquetball or let's go play softball. you can still do fun things. And I think it's really important to build that personal connection because it's all about culture. It's all about everybody feeling That level of trust that even if we have a difference of opinion on how to implement something or how to test something, we can have that discussion and not take it personally because we know that though we're valued and we can feel safe to express opinions, point out problems. That's that's the prerequisite to success, right?
speaker-1: Definitely. So before we head into the quick fire round, I have one last question because you've had such great experience and been able to look ahead and help people with their careers. What do you think, over the next five, 10 years, because things are moving so fast, are core competencies? Do you think that traditional testers must develop to stay vital in the automated, AI-driven development workflows?
speaker-0: Well, clearly everybody needs to learn these AI tools and everybody seems to be able to learn them, right? Even the business people are cranking out prototypes and stuff, marketing people, whatever. But I think it's the communication. So we all have to keep speaking the same language. So, you know, Janet and I used to use the term technical awareness. Like you you may not be a coder, but you can learn how to read code and you can learn how to use the IDE so that you can sit down with a developer in person or remotely and your whatever IDE you're using, IntelliJ or JetBran, you know, whatever. Visual Studio, you can navigate around that well enough to understand what they're doing. And and so the same thing's true with any AI tools and stuff, cloud code, whatever, just being being familiar enough with those that you can have that conversations. And of course you want them to be able to talk testing with you, but they may or may not they may or may not do that. I don't know. we can certainly we can certainly encourage it. I mean I've always wherever I've worked, I've always done little workshops like let's have a little exploratory testing workshop or, you know, do have some fun, short half hour hour activity where people can try different testing things together. You know, let's try example mapping together, whatever it is. So still doing those kind of things. But yeah, it all it all comes down to communication skills, right? And and the other thing is just your attitude and mindset. So when I was hiring testers, I didn't look for specific skills. I didn't look for, they know how to make Selenium tests or they know how to do exploratory testing. I wanted to know that they're Very curious and eager to learn and they feel fine to ask questions and they're willing to just try anything. And I I can teach people the skills they need to know, or I can help them learn the skills they need to know, but I can't, it's harder to instill that kind of mindset with people. And so I would always pair with people, or sometimes if we could do it without overwhelming and try a little ensemble together to say, hey. Let's look at this UI page that we're working on, our team's working on right now. How would you go about testing this? And you know, feel free to ask any questions about it. and then see what questions they ask and see how fast they seem to pick things up. That's true no matter what technology we're using. Those kind of skills of eager to learn and able to learn, you know, quickly enough. and willing to just willing to try things out. Courage. 'Cause we all need courage.
speaker-1: I do think everyone needs courage and I think to all the managers out there, if you're wanting to help your teams the most, is kind of how do you give your teams the agency to feel courageous, I think is the thing for me as a manager. and I promise, not promise, but in my experience, if your teams have agency and they're feeling courageous, You don't really need to manage them that much because they just do amazing things.
speaker-0: Exactly. Exactly. You gotta hire hire the right people, hire good people and get out of their way.
speaker-1: Definitely. Awesome. So we're going to head into the quick fire round. This is where I ask you a few questions and the answers need to be fairly succinct. So I'll you like 30 seconds, 45 seconds to answer. But it's just kind of things that come off your mind when I ask the question and we'll go from there. Are you ready?
speaker-0: That's right as Oliver B.
speaker-1: favorite testing tool or concept that you've used across your career.
speaker-0: Are so many. but actually when I think about it, and I tell people this a lot, the favorite technique I ever learned to help me the most and help my teams the most testing is mind mapping. I learned it at a conference back in 2006. And I brought it back to my team and taught my team and taught our product owner, and I'm telling you. It's just done so much in terms of helping us think outside the box, which is so important. Do that lateral thinking, that creative thinking, creative problem solving, looking at risks, looking at what's important to customers, all those things. Having that thing you can do together, 'cause even on a virtual whiteboard, everybody can draw together and add nodes and go off on branches and ideas and it helps us have a conversation and we can use them as a test plan. We can use them for so many things. So That's by far the most I I plan my day with a mind map. You can just do so many things with it.
speaker-1: Wow, cool. What is one book every QA lead or software engineer should read in 2026?
speaker-0: There are so many books and really great ones coming out all the time. But I'm gonna go with a classic because l like you say, a lot of the books they don't get out of date. And I'm gonna go with well, just two books, Fearless Change and More Fearless Change by Linda Rising and Mary Lynn Manns. And they're patterns for helping us influence change or spark change in our organizations because we're all faced with that. Yeah. You know, we all say, the developers they're not they're not doing unit testing. How could we get them to do unit testing? Or the tool we're using is not right for us. How can we convince management that we need to go a different direction with that? Or our process needs changing, or we need to have a process retrospective. Whatever it is, I know every and everybody I know has always felt that frustration. And and sometimes feel like It's just hopeless I won't be able to change. But we all can be change agents and you have to try. And these little patterns are little things you can try quickly. And if it doesn't work, you go on to the next one. So for example, one of them is the elevator speech. Of course, this goes back to the days we're co-located, but if you got into the elevator with the CTO, have your 15 second speech prepared for the thing you want that person to think about. Yeah. Be ready and take the opportunity. Or, you know, simple things like find an ally, find somebody who thinks like you do. Now you can brainstorm together and maybe now you can go more allies and you can just get your initiative going that way. the other pattern that worked really well for me when I was on a co located team is do food. Because you can get anybody to come come to a meeting room and look at something if you provide, you know, brownies or cheese or something, pizza, whatever they want. so It's just a for me working in a you know, I've work gotten in organizations where I thought, well, they're they're agile, they're gonna do the thing and then realize, no, they're very dysfunctional. How can I en effect any change? And it gave me tools to try that. Now sometimes it doesn't you know, sometimes you try everything and it didn't work and then change your organization or change your organization, right? But I think f across the board, those books help everybody.
speaker-1: Awesome. What do you consider the most underhyped QA metric?
speaker-0: Hmm. Well, I'm a fan of Google's Dora Key metrics, which came out of many years of scientific research of what the teams that are high performing, that please their customers, that make their businesses profitable and that are happy, what practices do they do? And the metrics that I think that are that can really reflect, especially process quality, which you need process quality. to get product quality or things like how frequently do we deliver, what's our cycle time, how long from when we start something to when we finish, because that correlates with those small chunks, frequent delivery. those are those would be my two favorite ones. There are other ones that I think are good, but Perfect. To really focus us on doing one small thing at a time, doing it well.
speaker-1: What's the most underrated skill for testers today?
speaker-0: what I already talked about, the commu those communication skills and what Janet and I used we we cook and I think we got this from Isabel Evans actually is thinking skills. So some people say soft skills, some people say harder skills because they are harder. But being able to communicate and collaborate with people is so essential because we can't have that holistic approach with everybody on the team owning quality and working hard to build it in if we can't. communicate with each other. So Awesome. And yet nobody says people send their people to training on how to use this tool or that tool or that programming language. They don't ever send them to communication class.
speaker-1: is very true. Very, very true. If you weren't working in software testing or tech, what career path do think you would have pursued?
speaker-0: you know, like everybody, I accidentally got into this. when I was a child I wanted to well, I wanted to be an artist. and I wanted to be a writer, writer, R I T E R and I also wanted a ranch 'cause I I was horsey. Now I have donkeys, but I used to have horses. And so yeah, I wanted a ranch in the mountains where I could paint and write. Painting turns out not to be a skill that I have. I appreciate art. But written books, not the creative writing I had in mind. But I do live in the on a ranch. There's a a mountain right next right we can see outside our window it's a small mountain. It's not the ones we used to have in Colorado. And I can see the Adirondacks across the lake in New York from our property. So it's kind of the ch the dream. So I could have gone either way.
speaker-1: Awesome. And final question, what book, podcast or person has influenced your thinking the most recently?
speaker-0: Well, I have to see. I I still gotta go with Janet, although she's trying to be retired. I'm not an idea person. And Janet's always been the one to come up with the ideas and then I go try out and then try to share with everybody. And though she says she's actually she is the artist, so she has devoted most of her time to improving her painting skills. But she's still she's still on LinkedIn every day. She still points me to interesting articles and we still do a lot of writing and and podcast or video chats together. And she's still the person that always she sees it from that angle that I missed. And so it's hard not working with her as much as we used to, but I still cling to that bit of inspiration that she provides me.
speaker-1: amazing. This has been an amazing recording. I enjoyed every minute of it. Thank you so much for sharing your insights, your practicalities, deep history, everything. Thank you so much for joining me today.
speaker-0: Well, thank you. It gives me some more energy to go out and learn new things.
speaker-1: Awesome. If people wanted to see what you're doing, follow you, what is the best way for them to do that?
speaker-0: As far as social media, I'm mainly on LinkedIn, so you can find me there. Just look for my name and then LisaCrispin dot com is my website and it has links to our gents and my book website and our training website and things you can find all that there.
speaker-1: Amazing. And to everyone who's listened or watched, please don't forget to hit the Subscribe or Follow button for browser stack talks on your favorite platform so you can never miss an episode. And hopefully we will see you soon. Thank you all.
speaker-0: Thank you.
