Awesome Software Testing Strategies with Matthew Heusser and Michael Larsen

Foreign.

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast and in for a super special treat today. Today we have Matt Heuser and Michael Lawson sharing all about their new book, Software Testing Strategies. Matt's been on the show way back in 2015 and Michael, I've been trying to get him on the show but hasn't been on in a while. I haven't been able to get him on until now. So really excited to have him. As you can tell, these books are ready to fly off the shelves. So definitely after the podcast you're going to want to pick up a copy and you want to stay all the way to the end because we're going to have a special discount code for you, if you don't know. Matt's career spans over three decades during which he's been at the forefront of software testing leadership. In 2014 he was honored with the Most Influential Agile Professional Person Award at the Agile Testing Days and the following year he received the award for the most popular online contributor to Agile at the Agile Awards in London. Matthew's dedication is evident through all the contributions to he's made over the years. If you go on YouTube, he has sessions all over the place. He's been a speaker, conference organizer, consultant and writer. And Michael Larson's the same thing. You probably heard of him. He's been around since at least I think, I think his blog post out in 2010, which is test Head, he's worked with various companies and products over the years. He lives in the Bay Area and he's always been really into software testing quality and also leadership. And he also has served as a member of the Board of Directors and president of the association of Software Testing and the marketing chair for the Pacific Northwest Software Quality Conference. And if you don't know, he's an awesome singer. So definitely maybe we'll have some links to that as well. You don't want to miss this episode. Check it out. Hey guys, welcome to the Guild.

Thank you very much.

It's great to be here. Thanks. Thanks Joe.

Oh, it's great to have you both. Like I said, Matt last we spoke was actually in 2015, so it's great to have you back. And Michael, we just keep missing. I think I've been trying to get you on the show for 10 years. So it's awesome that Matt finally pulled you in. So thank you for that.

Glad to finally be here. I know it's been back and forth. I think the last time that you and I directly interacted was when we went all virtual.

But it's great to have you on officially because this, this is. Like I said, I've been waiting for this for a while. So thank you. I'm really excited about this episode because I, as you could tell, I love books. And so I was excited to find out when I saw you have. So today I just want to focus basically on and obviously wherever we go, on it, but on your new book, which is on software testing strategies. So before we get into it, I always ask authors this. If you could pull up that book, let me get a good look at this book so people can check this out. Look at that. First question I always ask authors is, why write a book? I know you both are super, uber, uber busy, so let's start with you, Matt. Why? Why write a book? I know you've written a few before you edit a few, but why this one?

And short answer is somebody called me and said, we want you to write a book. And that's very different than kind of pushing out like, I've got a book proposal. Would you please pay attention to me? And Michael and I have been working together for at least 13 years, and we got a lot of experiences. And you have these experiences. They got to come out. You know, you end up, you either do a conference talk or you walk on the side of the road waving your arms and talking to yourself, or maybe do a blog post, but there's no single plate place to go for all of the material. The other interesting thing that started to happen was.

We would go to conferences and try, I'm a doctor, Let me solve your problems. It's very satisfying. But where could people go to learn all this stuff? So someone challenged us to make a course. Fine. Lean software testing course made the course. Well, then coronavirus happened. Or some people don't have a travel budget, so how can we spread it even further?

And that.

And that's the book. So I think it's about three ideas or three reasons why. I think it's about three reasons why the timing was finally right. After being around for a while that I think we actually had something new to share.

14 years of podcasting, we had come across a whole lot of conversations. We had had talked to a bunch of people, and we realized that there were Variations on themes. And we realized that there were, I think when we got right down to it, that there were three big areas that if I was going to talk, if we were going to talk about testing, we would probably want to cover this. And, and so the first area, of course, was your testing skills. And automation of course fits into that. But there's a lot more to testing than just automation, as we well know. In fact, in some cases I will be blasphemous and say that automation might be one of the easier skills to pick up. And I don't mean that automation is easy. What I mean is that it's fairly cut and dry when you get right down to it. You can program certain things, you can have certain expected responses. Once you have a really good feel for what's happening with something and you know where you're going with it, then you can get into automation. And also my view of automation is that there's a lot more to it than just firing up your ide, pulling up something like playwright or selenium, and writing assert statements. Anything can be automation. When you're setting up the bulk of your stuff for your environment, all those little niggly bits you got to deal with just to get the app to run in the first place, you realize, oh yeah, I got to do this, got to do this, got to make sure this loads, got to make sure I've got this running in the background, all these stuff. And once you realize what those are, you want to make sure that they're running. You throw those in a script file or you throw those in a startup file when you first fire on your computer, everything in place, fantastic. And you realize that over time, those are the things you're going to always have to do. So we're going to talk about this a bit when we come into test strategy. And the phrase that we refer to is recipes, right? You use a lot of recipes when you want to cook at first, but of course, once you get a lot of that under your belt, you start to play with flavor profiles rather than following a recipe line by line. So that's part of it. So there are skills that you learn. So that's the first section. And the second section is a strategy that you want to utilize and you want to be able to put this, plug those pieces together as you need to and be able to communicate what you're doing. And then the third part was just the actual day to day details of what we do as testers. And we realized through the podcast that a lot of that was what we refer to as the politics of testing. And so by the time that we had looked at all this, we said, you know, there's some interesting areas here. And I don't think that we've really seen a lot of talk about the politics or the political side of testing. And I don't mean like the same way that we look at it from a. From a government standpoint, but the way that we just live in and interact with people as software testers, as software engineering professionals, however you want to fill it in, you're going to get differing reactions from people. Sometimes you're going to have great experiences, sometimes you're going to have dreadful experiences. And knowing how to interact with those is really important. So there you go. That's a big, long spiel for what got us into doing it.

Awesome. So, once again, 16 chapters. It's broken into three parts. The first one is the practice of software testing. The second part is testing and software delivery. And the third is practice and politics. So we're going to dive in. I like to dive into each one. Just give people a little taste, a little flavor, so they know, ooh, that's tasty. Like you mentioned, very flavorful. So you have to grab the book to actually know how to make the recipe and then make your own flavor profile, as it sounds like. So I guess both, all our backgrounds, you mentioned automation and is kind of the easier thing. But I assume, I'm not saying we're old, but we are older, so we probably already had testing skills or QA skills before we actually got into the tooling. But it seems nowadays people start off with tooling. But I don't know if I'm being a grumpy old man. So is that why you started off with this particular chapter on testing and debugging test or what's this all about?

One of the things that we can do, which I don't think is particularly difficult to learn, is go into a project that has quality problems and just start testing and finding defects. On day one. We've got reference customers that we come in. It takes six weeks to get up to speed, blah, blah, blah. Okay, well, here's some defects and quick attacks was a term for one of. One of the. One of the ways to do that. It's actually pretty shallow format testing, but a lot of people don't know it. So we're going to start do this right now. You might add, you might find some value. And then from there we kind of work backwards into here's how to Analyze the combinatorics of the system to figure out some more test ideas. It's really interesting because there's an infinite number of possible tests. In fact, with things like memory leaks and race conditions, you could run the same test five seconds later and it might actually have a defect you didn't have before. There's an infinite number, and that's even before you get into the 5 of these and 4 of these and 7 of those, 9 of those and 11 of those infinite number of combinations. So what the techniques actually do is they reduce your number of things to do to generate some information about the system. But people tend to think of test techniques as a way to come up with things to do. Either way, we want to come up with very, very powerful things to do to.

Learn information about the system that we're working on. Like if you don't know what you're going to do, and you certainly don't have a way to find out the most powerful things to do, and you don't have a way to take the information that that comes away with to have knowledge about the system, then what the heck is your automation even doing? Like automating.

What?

All right, we're going to click this and get the answer of seven. Okay. What does that tell us? Why do we pick those things to do? Because they were in the acceptance criteria. Why are they in the acceptance criteria? Once we've run them, what do we know? If you can't answer those questions, you need chapter one. Now, what I would say before we go on, if you're a more senior type and you're getting this book, I've been around, Matt. I've read a book before. Great, Fantastic. We love you. We genuinely believe this pushes the needle forward on software testing. But you probably can go through the table of contents and find the things that are either most interesting to you or new to you. And it'll be a gold mine of value if you want to read it from COVID to cover, as some really, really Tim Western, very senior tester said, no, I'm going to read the whole thing cover to cover. Fine, but it's going to be more like a coal mine. You're going to get these nuggets that are of some value all the way through. Either way is great.

So now you mentioned, you know, from a customer's point of view, things they may do or may not do based on what your developers think. And in your book, you have a few chapters that go over, like programmer facing testing, and then you have customer facing testing and Then specializing testing. So why break out those as different chapters rather than have it all under the umbrella of testing?

Well, you got to break it out somehow. You want to have chapters in your book, right.

But importantly, I think that the ideas that caused you to be successful in one of those arenas will cause you to fail in another. And if you look at some really wonderful, smart, articulate leaders in the community that seem to have no ability to talk to each other, it's because they have assumed one of those perspectives and then the whole world is like that. So you can get.

And I want to put this in. If we do a second, I don't think we talk about the reliability.

Modeling reliability. If you're thinking about system reliability, right. So if your system is a combination of little pieces and each piece has 80% reliability and a walkthrough system is going to touch 12 pieces, presupposing, you could reliably put a percentage on reliability. Right. It's a model, you know, your, your overall reliability is going to be 0.8 to the 12th, which means it's not going to work. It's not going to work. Right. 0.8 to the 12th as a. It's going to be like it's not going to work. So you need to radically improve that. And one way to do that is with developer facing unit tests. You get that to 90, 95, 99, it's a 99% reliability and your whole system is going to be pretty good. So the classic testing way to do it was to put everything together which didn't work and then try to test the quality out at the system level. Didn't do.

That, was suboptimal, I guess. I would say so. But the unit test way of thinking, the unit test, identify the inputs, identify the outputs, identify the transformations, write the code to do it, develop seams, test the seam level. Fantastic, brilliant, wonderful. Try that for customer facing testing.

And particularly if you believe in just sort of walking the user journey for your tests.

Your tests are going to be slow, they're going to be brittle, you're not going to learn much and they're going to break a lot when you make changes. So you need a different kind of thinking when it comes to those other kinds of testing. And frankly, Michael knows a lot more than I do when it comes to things like accessibility and usability. Entirely different skill set. So it's only one chapter, but we at least could put enough in there if you really know what's different and.

Know where to go for more specialized testing. Reason I wanted to get into that is because when you've tested for a while, you, you can develop the hubris to say, I can test anything, right, Because I'm a tester, I put me into anything. I could figure it out. And on a superficial level, that's true. But there is domain knowledge, there is certain things that if you don't understand the underlying framework of that, you can get yourself into trouble and. Or if not necessarily get yourself into trouble, you can struggle with being effective. And I had that experience. I went into a business that. Oh, yeah, no, the software side of things and all that, that was, you know, I could certainly do that. But really, this was a company that specialized in touch screens and touch devices. And what were they testing? They were testing the laws of physics, they were testing capacitance, they were testing resistance, they were testing environmental factors that I struggled with. And it got to the point to where one of the people there was basically saying, you know, Michael, I've been looking at your resume. Now, when your manager says, I've been looking at your resume, that's a terrifying conversation to have. And I'm sharing this with full, full openness that this was a very real time in my life on this, where they were saying, you tested routers because you worked at Cisco Systems, you did a lot of networking type of stuff. You do that. I don't see that you've worked with this type of scientific physics stuff before. And he was right, I hadn't. And we had a, you know, it says, he says, look, I'm not trying to say that I want you out or that this is going to be a bad thing. I just want to counsel you that, honestly, with the number of the things that we're going to be looking at and number of the projects that are coming up here, if you don't have a background in theoretical physics, some of this stuff is going to be very difficult. And you might really find that this job is going to be painful.

I think that's sort of. That our two perspectives kind of merge and hopefully get a better thing for the reader. A lot of times in testing.

Over.

The years, I've seen a lot of testers say, we don't do that. We don't do that. We don't do that with scope management, you know, like, no, no, no. We just do this little thing here. Well, when you do that.

Your value is lower. So, yeah, it's really, really easy to do the three things that you do, but look out, because someone's going to come around and Try to promise to management to get rid of you. We got fruity DevOps, Lucky Charms. And you don't need that because we're doing a B split testing in the cloud with crowd and all of a sudden you ain't got no job. And by the way I speak this colloquy way of speaking, I, I think it's funny. So. But I'm trying to make a point. So. But what you can say is, yeah, I know how to do that. I, I can figure out how to do that. If you become the person in the office with. How are we going to do that? I guess we're going to hire a consultant. We'll call Exelon. Those guys charge like a whole lot of money. I don't know. I can figure out how to do that. If we can put enough in the book that you can say, I can figure out, I know what it is, I could figure it out. Go get references. I got contacts. We can at least provide you to tell you whether we're in over our heads or not. You know, if, if the thing falls apart when four simultaneous user hits it, we got a real problem. And if it doesn't, maybe we could take more time in doing this research.

And I think that's really valuable to have that approach to it. I don't know it. I can probably figure it out. I know enough about it to be dangerous. I think that's really valuable. And I think the book, I think we did that. I think we keep that promise in the book.

I love that about the book. Matthew. So you mentioned something that makes a good point. When I had a real job five years ago, basically been unemployed for five years. But when I had a real job, I never waited for people to tell me to do something or say, this is all you do. I would get a book like this, I would learn a technique, I would try it on my own and then show my team. Is that the approach you recommend as well? Using a resource like this, it's like, like you said, it'll make you more employable as well. Rather than just being pigeonholed by your team. Find ways to add value within your team because they don't necessarily know what they don't know. And by reading a book like this, you might get the knowledge, say, all this technique is going to work here. Yes, we don't do it. Yes, it's not what we do. But if I imply it, I know I'm going to add more value to my company.

I will tell you while we wait, I will Tell you another story that it's part of it is in the book, but I'm going to elaborate it for our audience.

And I worked at an insurance company and was relatively large software organization.

It was in Microsoft, but it was. We had enough teams that we had specialized roles so there'd be a problem and the DBAs would say that's the web devs problem. When the web devs would say the production app support team needs to work on it. And the production app support team would say it's an application development issue and application development say it's data warehouse. Data warehouse guys would say it's a dbas. And this was not, not an uncommon problem to the point that they created a technical project management team just to take responsibility for things and, and figure it out. Because the business side, project management, they couldn't. It was like speaking Greek, you know, the technical project man. At least we had computer science degrees. It's like, wait a minute. No, no, no, no, no, no. It's a problem with the index on the database. That's you. And in theory, but in, in practice that we still struggled with that. And one of the things I noticed this, this happened.

It's a little embarrassing, it's a little awkward, but I'll share it. One of the things that happened, I remember my last day I left the company. I was having like the goodbye party kind of a thing. And my manager who was a lead so he had projects he was running, it was also kind of a celebration or kind of one of the projects he was on. So we all had, we all went out to eat and he mentioned one particular project, project fu. And he said, yeah, I wish I could take responsibility for it. The technical project management team, we were invented to take responsibility for it, but I really can't. You know, no one could have foreseen what the things that went wrong. And my jaw dropped because I had emailed him a list of exactly what was going to happen four months before any of it happened. These are the problems. These are the people who are not delivering their stuff. These are the things in the Gantt chart that are blocked. And I do not believe these people will be successful if they continue with this approach. It was detailed, specific, it was organized. Everything that went wrong. What's interesting about that guy, and.

This is awkward.

He kept getting promoted. He would leave organizations and under difficult circumstances. I know in one of them.

Security escorted him out and he would land somewhere else as a mid to senior level executive. He had stuff on his resume that didn't make sense stuff on his resume that was. Was ascii, word for word, cut and paste to someone else I knew at the organization, and he couldn't explain what it meant. You know.

I'm not sure how much detail I should go into here, but. But things like that's.

Reduced business process defects by 65%. And I knew what the other person meant by that. They had a. They. You know.

They had a justification. Right. And it was kind of smarmy, but I knew what they meant. Okay. And there. There was a 65% reduction in a certain kind of thing that you could count. This guy just cut and pasted it. He wasn't in the room.

But that behavior was rewarded. He got promoted. So the question that I would ask is, are you willing to sacrifice your integrity and morality at the altar of your promotion? Because if you can, there's a. You don't buy our book. This book is called corporate confidential 50 secrets to succeed in the Business Today. Michael and I chose a different path. And I'm not saying we're perfect.

The one thing about the ethics chapter is it sounds kind of preachy. We make mistakes all the time, but we at least give you an ethical framework so you can make decisions, so you can sleep at night. And I think that's worth something. Oh, and the reason I told that story was actually going to zoom way back out is that there was an organization where you could succeed by saying, we don't do that. That's another team.

So he said, it's not my responsibility when, like his team was created to make it their responsibility.

But another way to do it is. And the people I know that have been there are still there for a long time. Many of them. What they do is. I can figure it out. I'll do it. Yeah, I'll do it. You know, no one else is stepping up. I don't know Anything about Oracle 9.7 drivers Legacy working with this system. And we got to upgrade it because that's just ancient. It's gonna. Gonna. The wheels are gonna fall off and it's not supported in the cloud. But, you know, I'll try to upgrade that box and see what happens. And then we'll try to run it. We'll try to put it in AWS once it's upgraded, I'll do it.

The person that takes on that responsibility, even though it isn't a test responsibility long term, we think has better outcomes.

Give a chapter actually on words and language about work.

It oftentimes comes down to if you are not saying the same thing or if you have two different understandings of what something is about, you could be on the wrong path and you could be focusing on.

The main thing or what you think the main thing is and you could have totally different reasons. And mind you, there's a little bit of if you will, cya, you know, cover your butt if you will. And in some cases people will be very guarded in their speech or they'll say things in a way where there's a lot of equivocation. In other words, I want you to do X, but don't dig too deep into X because if it makes us slip our schedule or if we have to somehow do something different, that's going to be a big problem for us. So you run into the, you know, we refer to it as weasel words or oh, I didn't actually say that, I didn't mean that to happen. And we give a, give an example of some, of, some of some corporate situations to where somebody did do that. Well, we needed to stay on schedule. We needed to make sure that something happened. And by virtue of that, a very big issue was uncovered and it was a big scandal. I, I'm pretty sure that that was VW that we were talking about in that regard in regards to their emissions numbers that they had to roll back and say, you know, we did, didn't do this. Right. And well, I never meant for you to do that. That was never the case. Well.

Can'T be necessarily proven, but I'm willing to bet the answer is, yeah, that probably was the reason you were under pressure. You had to make sure that your test passed. And so you did things to make sure the test passed. And that's danger. And also oftentimes when we as the testers are in that situation, if something goes wrong with the quality of something, they're going to look at the test team first. It's the old phrase of the tester gets called out on the carpet. Why did you let that bug go through? And in my younger years I used to just say, oh, I'm so sorry, I can't believe I missed that. I'm such an idiot. Later on I said, I don't know why did your programmer put it in?

I said, no, no, no, we're not playing this game anymore. I'm not going to let you take software test and say we are the reason that this bug went out. We're part of it, but so is your programmers, so are the people that work here, so are whatever reasons come into this and it's important to have those conversations. And yeah, that is a part of the politics of testing.

You know, one thing that I think is worth talking about is this. And maybe you disagree, Joe. I think this is really important. And we kind of picked a fight with this in the book.

We like the Hegean synthesis, we like the idea and the counter idea, and then work them together to find a third that's even better. So we don't use the term qa. It's all kinds of problems. And yet I'm totally fine with you using the term qa. In fact, you might disagree, but when I people post on LinkedIn, it's impossible to do quality assurance. How dare you use the term qa? And I say, I do qa. I do it all day long. My company does it. We'll do it for you. We're just very expensive.

I joke. We're actually pretty darn competitive on pricing in the US but for testing services. But we can do qa because people haven't really liked, really looked at the dictionary definition of assurance. They don't really look at it. So, you know.

When I was married, if my wife said, what time are you going to be home? I could say five o' clock. And she'd say, no, there's a roast in the oven, the neighbors are coming over. I really want to know what time you're going to be home. You need to provide me assurance. None of this five, ten minutes late stuff. What time do I have the food coming out of the oven? It'll be five minutes after you get home. I need to know when to put it in. I need your assurance on when you come home right now. If I said 6 o', clock, I'll be home by 6 o'.

Clock.

I assure you. I have assured her I'll be home by 6 o'. Clock. Right now, that's the English definition of the word assure. If my car has a flat tire and I have to call AAA and it takes them longer than we thought and I get home by 7, is anybody gonna point their finger in my face and say, you aren't really providing assurance? You can't claim to provide assurance because you can't guarantee that you'll be home on time. Well, that's not what assurance means. I assured her. She's gonna say, I'm so sorry, that's so terrible. I hope it wasn't to get too cold for you out in the snow while you're waiting for the tow truck. Everything's going to be fine. Everyone is going to understand. Right. So when we say testing is complete or we've allocated this much time for risk mitigation, these are the things we found. If we had more time, these are the things we looked into. Do you really care about these risks? Given that these are the things we think are the highest risk and these are the things we found and you, you, you want to send the software out anyway, does it really matter that we keep testing? That's a very high, mature conversation. We'll teach you how to have it. And you can say, I'm fine with you saying I provide quality assurance. Now there may be times when you say, okay, the decision is to put this out. I think it's hot garbage. I can't assure you that it's quality because I don't think it is. You get to do that too. But if you want to use the term qa, I don't have a problem with it. We provide a theoretical justification for it in the book. I'm happy to have that conversation with anyone anytime. I think it'd be a good debate at a conference.

Absolutely.

And I changed my mind by actually, I don't know, looking up the definition of the word sure and really doing some work.

I love this book. It's full of models, it's full of patterns, real world examples, case studies. So as people could tell by hearing this, you definitely need to pick it up. Right, guys, before we go though, any parting words of wisdom? Where can people pick up software testing strategies?

The book is on Amazon. If you go to pact.com p a c t.com and you look for it and use the code STS25 through.

The end of middle of March, it might be end of March, we'll get it extended. You can get 25% off. And if you get the ebook, which is cheaper than the Kindle book, which is cheaper than the real book, you get it from pack, you don't get it from Kindle then and you use the coupon. If you really, really. If you don't want to spend money.

You can get it cheap. There are some trade offs involved. If you get the PDF, you, the links don't work. If you click on things, some things but, but it's a sweet, it's a sweet deal. If the other final thing I want to. Let's, let's criticize testing community. We love being super precise in testing community. We say things like, oh, I didn't show, prove that it works. I'm not quality assurance. I just demonstrated that it can work under precise conditions. One time. Hahaha. So don't you come coming to me when it doesn't work so well. Okay? That's a very weak claim. You know.

My middle daughter, when she was in sixth grade and she was sort of apprenticing with me, she could say similar things. She's a lot cheaper than most software testers are. So we have an infinite number of combinations we need to select the most powerful tests and then from so I got a degree in math in a hypothetically infinite series of possibilities. Selecting a finite set tells you nothing because there's an infinite number of infinities. So you can multiply infinite by infinity and you can make your finite set, no matter how big it is, meaninglessly small. Right. It's a impossible, you know, nothing. Right? And yet we are tasked with figuring it out anyway. And we can and we do. And this book will tell you how. And I think that is a pretty strong claim and I'm proud to make it publicly. And if you disagree, let's talk.

And I will also add to this, in addition to you can get the book pretty much anywhere that physical and digital books are sold, online especially. But also I want to add that Matt and I have also set up communities. We've got a Facebook group, we've got a LinkedIn group, and heck, if there's another place you want us to put it together, we'll do it there. But we want this to not just be hey, here's a book, go read it. And that's it. We're here. We're active participants in the community. That's something that we've prided ourselves on. It's part of the reason why we've been involved in organizations like AST and myself currently with PNSQC is that I want to continue to be part of the community regardless of what work I do. Whether I in the future, whether or not I do more writing or whether or not I do more testing for an organization, or if I just become a full time testing consultant in some capacity or who knows, maybe I'll put more of my attention into music production and writing or doing other stuff. My point is, is that this is the work that I've spent 30 years plus doing and I'm pretty passionate about it and I'll be passionate about it regardless of if I like like you, Joe, if I still have a day job five years from now, I will still want to be involved in this because this is the stuff that matters to me. So we want to have those conversations with you and we have ways to do that. If you want to join the group on LinkedIn, if you want to join the group on Facebook, reach out to us. And Matt and I are both there and you can find us on LinkedIn pretty easily. And basically our only thing that we say is you show us you've got a book, you're in.

You know, one of my great, my great disappointment with the Rational Unified process, Rob, is from what I can tell, they weren't really interested in transference rate. Like, here's a bunch of ideas. I wrote a big book. Did it work for you? How did it work for you? What did you have to change a year later? Was it still working for you? What did you learn? Well, where are the case studies? Where are the adoption studies? Where are the.

I don't think it's controversial for me to say the people behind the rational Unified process weren't particularly interested in that part of the story. And we're particularly interested in that the next step is going to be do people pick up the ideas and use them. Otherwise it's going to be a dusty old book you can get at a really big library if you're lucky. We want to do better than that.

Absolutely. So definitely check it out folks. We'll have the link down below along with a discount code. So let's spread these ideas. Obviously, as you can hear from these experts, definitely worth spreading and helping others along the way as well with them. Awesome. Thank you guys. Appreciate your time.

Thank you very much. Thanks for having us.

Thanks again for your automation awesomeness. The links to evident value we covered in this episode head on over to testguild.com a491 and if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the the skills or solve a problem for the guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.