The Testing Show: The Secret Weapon of QA Modernization

 

 

 

Panelists:

 

 

 

 

References:

• The Drive Through is not Always Faster
• Bridgetree
• The Secret Weapon of QA Modernization
• Quali
• Site Reliability Engineering

 

Transcript:

Michael Larsen (00:00):

Hello everybody. And welcome to The Testing Show. It is June, 2020. We are currently still dealing with the fun and creative factors that make up COVID-19… and I’m using fun very facetiously. However, that is also (as has been the case for the last few months) been driving our topics and this month is no different. First off, we would like to welcome Maya Ber Lerner to the show.

Maya Ber Lerner (00:30):

Hi!

Michael Larsen (00:30):

Also like to welcome returning guests, Leandro Melendez.

Leandro Melendez (00:36):

Hello, Amigos. Thank you for having me here.

Michael Larsen (00:39):

And did I say that right?

Leandro Melendez (00:41):

Yeah, that was very good.

Michael Larsen (00:41):

Awesome. Yes. Thank you. We would also like to welcome back Mike Lyles.

Mike Lyles (00:47):

Hello everyone.

Michael Larsen (00:48):

And of course, our master of ceremonies, Mr. Matthew Heusser, and I’m going to turn the mic over to him and let him do his thing.

Matthew Heusser (00:56):

Thanks, Michael. If you’re a longtime listener. You know, me, you know Michael, we’ve had Leandro on at least once or twice now. He’s… I would say performance engineering consultant for Qualitest. Is that close?

Leandro Melendez (01:10):

Yeah. Most of the time I’m providing services and managing some of the performance testing tasks here at Qualitest.

Matthew Heusser (01:17):

And Mike does a lot of things. I got to know him when he was at Lowe’s as a test manager. And now I think he’s running a division of a group that does… well, tell us about what you’re doing now, Mike.

Mike Lyles (01:34):

Yeah, so I work with a company called Bridgetree. We’re a marketing services company and I came on board to be their Director of QA and ended up being the Director of QA and Project Management both, which is a very interesting job to have leading both of those groups together. I’ve been doing that almost four years now.

Matthew Heusser (01:52):

Great. And you just got a book out. Y.

Mike Lyles (01:54):

Yeah, it’s called “The Drive Through is Not Always Faster.” During the coronavirus, it’s not a theory that’s true right now ’cause the drive through is the *only* way, but it’s a really good book. Self-help, 30 chapters. Each chapter is a different story. Easy to read. A lot of people are reading it one a day. So, I hope you get to check it out.

Matthew Heusser (02:13):

Yeah, we’ve been talking about leadership on the back channel for a long time now and it’s good to see some of these ideas coming out into the world. The real news person for the show and the reason we’re kind of having it themed this week is, “The Secret Weapon of QA Modernization”, which is some material that Leandro and Maya put together. I don’t know Maya real well. She’s the CTO of Quali, which I thought was a division of Qualitest. Well, it’s not. So maybe you can tell us about that.

Maya Ber Lerner (02:42):

Yeah. That’s the obvious question. No, Quali and Qualitest are completely separate companies. Actually, even though we share a magnificent name, in a way, I am indeed the Chief Technology Officer at Quali, since I suffer from overcommitment, I’ve been with Quali for tons of time. Over 12 years. But I wasn’t bored. Did a bunch of different jobs. Everything is really focused on infrastructure automation and a lot of development and testing. For Quali, I’ve also been VP of Product Management. So I also have this aspect in my career and I’m based in New York. So I think now, you know everything about me.

Matthew Heusser (03:22):

Well, I doubt it, but let’s start with “The Secret Weapon of QA Modernization”. What’s the secret weapon, Maya? That’s a strong claim.

Maya Ber Lerner (03:32):

Yeah. It is a strong claim. And you want me to give it just like that… but I will. I think the secret weapon of automation is infrastructure automation. It’s secret because not a lot of people think about it when they think about making automation better and about making quality faster. But actually it’s always there lurking under the surface and waiting to slow you down. And if you get rid of this slowness, you can be very, very fast.

Matthew Heusser (03:59):

I completely agree, by the way. I’m going to jump out of my moderator role for a minute. When I go into consulting organizations and they say, “We want to do test automation”. That’s great. How long does it take you to do a build? “About a day”. What about setting up the test environment and test data? “Oh, a couple days”. Okay. So you say, “I want a new system to test on that has known good data so we could send problems in and get answers out and we know what the answers should be”. And that takes you three days. “Well, change control needs a couple of days to get ready for that”. Even if you made automation instant and free and evaluation without any errors and without any false, “This changed. So we got an error, but it’s not actually an error” and you never had that and you press a button. It was automatic. It would still take you five business days to do testing. And there’s jaws drops and they say, “Whaaaaat?!”. So yes, automating the infrastructure right. Which leads me to wonder, “why is it so often ignored?”

Leandro Melendez (05:04):

If I may, I wanted to add in to some of those experiences, situations being on the field and learning, experiencing many of these problems. How many of us have tried to automate or to execute some automated tests and find out that the test start to fail because the environment was misconfigured, has something wrong, the data doesn’t match. On top of that, another big, big problem that we face often in these situations is that the environments have to be passed over, to call it in a way, when we have the functional team using it, you have to wait until they are done with their thing so that UAT can start… from my perspective performance can start at the very, very end when you have only 10 minutes before the release, many of these situations with these environments that are not available, take a long time to set up, to configure, and are prone to human error situations that can arise when you are trying to quickly bring up an environment, do your executions, be done with it, and try not to step on everybody else’s toes. This is the situation that we face, I think, at least on my end, as consultant, as, as you say, Matt being on the field, it’s so often, and it’s such a huge problem. On top of that, I’m going to add a little pinch from the performance perspective. When they do not match, not only in data and code, in other pieces, but infrastructure wise, load balancer was not configured. Servers, of course, are not the same size as production. Many of these limitations, we should not be facing them anymore. I think that’s part of what Maya was saying in terms of the secret weapon and the magic. It’s almost magic when you can have these types of things on a project.

Maya Ber Lerner (06:58):

You know, I want to add one more thing. I said that the secret weapon was automation, infrastructure automation, test environment automation. And when we talk about it, we talk about very technical things. Getting the infrastructure together and putting the right application versions and putting the right data and sanitized data, things like that and making that quicker. Another part of this secret weapon is to get it to a lot of people because automation is easy if you know automation, but getting it to a lot of people that need environments, that’s real magic.

Matthew Heusser (07:30):

So in practice, this means either when I gather… I have a build, I have a URL, I can click it… Or something, like a unique code and I can say, “I want that build as an environment. I want a complete environment.” Ideally I can say either I want a test environment or a performance environment that’s scaled just like production. And within what, 10 minutes, I should have it. I’m curious of the people here that have sort of more wide… can I ask Mike, Mike Lyles and we can come back to Leandro? What percentage of your customers actually have this and what do you think is the percentage in the real world?

Mike Lyles (08:09):

Well, that’s a great question. About eight years ago, I was… I was in the testing group, but I was under environments and data and service virtualization. One of the things that we noticed was with that very large retailer, we had hundreds of physical environments that we used. What we did was we turned those into virtual environments and implemented a build process that would be a full turnaround of a store system within like four hours. And I think that was revolutionary for that organization at that time, because it was taking days or weeks to build systems before that. And that sped up the process. It also reduced the number of systems that people hold onto. I’ve heard Maya and Leandro talk about people keep holding on to things and they don’t tear them down. And I, that was a big issue with the company I was with at the time. They hold on to it because they think it’s going to be harder to get another environment again or get it to that level. So I think that’s a big issue that I’m seeing. So we resolved it with guaranteeing folks that they could get it available within half a day. And it would be fully built with data and the latest code drops that were in the system at the time. That’s one example of a retailer that was really looking for ways to revolutionize that and really changed back in 2012. Well, I see a lot of companies today. Like our company, we keep test environments. I wouldn’t say that they’re an ideal match to production. I think we do some testing in production as well. I’ve heard a lot of talks about test in production and a lot of companies saying they no longer use staging systems.They use test in production. So I think that’s a topic we can address down the road but I do think that’s something I see a lot of companies do is provide the ability to do test in production and the ability to turn it on or off so that they can monitor that. The companies I’ve worked with, I heard these folks on a webinar talk about a very large banking company. I think they use a lot of environments. It’s one of our clients, but I don’t know how their staging looks compared to production. I think a lot of times what you see people doing is their performance systems are not a real ideal match to production. Getting things identical is really the struggle.

Matthew Heusser (10:28):

Michael, you have a question?

Michael Larsen (10:29):

I do, actually. I will admit I’m approaching this from a slightly selfish perspective. This is timely and it’s something that I’m very curious about because these things like, you know, doing infrastructure and set up an automation and all the things go with that. This sounds like something that works really well when you’re setting up a Greenfield environment or you’re setting up something for a relatively straightforward platform. My question is more along the lines of -if you’ve had experiences with this- how do you deal with interlocking products? I’ve talked about my company a few times on this show… more than a few times… in the sense that, what happens when you are working with a group that acquires multiple companies with multiple ways of doing things with the goal, ultimately of getting to a point to where you can fuse everything together and make it run in a seamless environment where everything works together? We can cue Don Quixote’s “To Dream the Impossible Dream” right now, if we want to but that is at least the goal. That’s what people are trying to aim for. Is that something you’ve had experience with? Is that something you can speak to or is that really still just kind of on the horizon? We’re hoping to get there. We’re not quite there yet. And if somebody wants to get there, what’s the best way to do it. I have a feeling just that question could probably fill up our time. So I’ll step back and let y’all talk.

Maya Ber Lerner (11:57):

Yeah. I’d like to take a stab at some of the questions. It’s a huge question. I really like the topic. I think it’s a great question because one of the things I see, as someone who does automation, infrastructure automation, is that you talk to people and they tell you, “Oh, we’re not a hundred percent cloud native so we can do it” or, “Oh yeah. If we had a Greenfield scenario, we would be able to do it” or, “Oh yeah. We’re just waiting to move everything to Kubernetes and then we will be able to do it”. And as an automation person, I think that’s not necessarily the right approach because there are so many ways to improve your velocity. As someone that looks at automation, usually what you do, you just take this big manual process that takes two weeks today or two months, right? When someone wants to get an environment or you need to run test automation environment, it takes you two weeks to get there. Or someone is holding it for six months. And now you’re saying, “Okay, I can save a lot by just making it one day or maybe half an hour”. There are so many things that you can do, right? And not all of it is a hundred percent automating everything and making everything be done at the click of a button. There’s a lot that can be done with semi-automation, with automation that is used to get something to a certain state or with automated self health checks or with… even conflict resolution. If you have physical assets, some people say, “Oh no, I’ve got this oldest mainframe legacy stuff. I just can’t automate”, but that’s not true. You can still do reservation. You can do smarter sharing of assets. You can have better visibility. You can manage things better. There’s so much to do in automation that’s not scary “Kubernetes. I’ll never get there” stuff.

Leandro Melendez (13:41):

Yeah. I would add as well for what you were mentioning, big organizations merging or bringing multiple systems together. This is a usual challenge regardless of what are you trying to do integrating those systems. But I believe the key here as Maya says, the benefits are tremendous and it only requires some pre-work to be done and to generate some of these blueprints from the new environments, regardless of where they come from. If you have the right tools, devices, and ways to adapt, you can bring almost any type of solution, as Maya mentioned, when she told me you can do this with a mainframe, I was like, “Oh wow!” Then those are huge capabilities that enable your organization to move faster, be able to execute whenever they need and quickly bring up, bring down. And I think one key characteristic here is to be able to also bring those probably in a selective manner where let’s say for performance, I just need something that resembles a load production. You bring up one that is almost equal. Well as equal as possible, as well as let’s say, I just need to test this functionality or do some integration and break up environments accordingly. That’s also a key capability to speed up some of these processes and integrate. But of course, when you are starting on these Greenfield situations, do you need to do some pre-work and put together the pieces needed for these environments to work?

Matthew Heusser (15:15):

One thing that I would add there and Maya said it is that if you just do an analysis, a theory of constraints, and how long is it taking for us to do a build? What are all the pieces? And then you find a long pole in the tent. What does a single activity that has the greatest delay? It might just mean we send a ticket to ops and they do a thing. Their service level agreement is it takes them three days to respond to that request. Could they just give us permission to do it? What is the risks that we do it? And you get all kinds of pushback. Like, “Oh no, that violates Sarbanes-Oxley. And we can’t do that because of Dodd Frank and there is a regulation and we can’t find it, blah, blah, blah. Okay. Like we shouldn’t spend a hundred thousand dollars on these test automation initiatives when there’s a three day delay to get a build and we can’t do it because we will either continue to pay this price on this delay, or you could let us do it, or we can build some automation to do it because it could be as simple as I got to FTP and click F5 and run the thing. And then of course we could build automation around that if we need an audit trail, but you might be surprised when you start looking at what is the actual delay in our last commit to deploy process and what is our pipeline as is and how can we make it faster? There might be a ton of opportunity in there. It’s just invisible because no person is looking at the whole thing holistically.

Mike Lyles (16:36):

You know, the one thing I’ve heard companies struggle with through the years is how close is my environment to production, especially for performance environment. If you’ve got a really large environment or a really large, expensive environment, whatever type of hardware you have or applications within it. The question for the group here is two questions. One is have you seen companies that are struggling to build test environments, that map to production? And then the second question is, is that required?

Leandro Melendez (17:07):

Yeah, of course. And this is a very relevant topic in the performance testing world as well. When you mentioned a production environment to be replicated, it also depends. Probably you cannot replicate completely. Let’s give a big-ass example, Amazon production environment. As well, it will depend on what you’re trying to test on it. If it’s just performance to measure some in response to some metrics, did you replicate a piece of the environment according to what you are needing, but if you are looking to do a load test and check the ceiling that the system will be able to handle it and that the application will be able to scale this big type of tests, you will try to simulate accordingly. Let’s say, bring up an environment. If it’s too big (production again), you don’t bring the whole Amazon infrastructure up for a load test. You segment it, you load it accordingly and put a, let’s say, on these geolocation to call it in a way we will have this amount of users. So let’s bring up a production like environment because of course you don’t have all the servers in the same place. You don’t have all the infrastructure. So up to a point, you need to start to segment these automated environments that will come up when the environment is not that large. And that’s another advantage for this secret weapon. You can bring up an environment that could be considerably big, not the largest example that I gave, but when you bring one that is considerably big, it’s put up together, you run your tests and you decommission it. You are not wasting that many resources. So at the moment that you need to do the big, big tests, you bring it up as needed realistically possible and execute a test, bring it down, and then you’re done with it. Yes, there are these limitations where if it’s a load test, you need to segment what you are trying to do and achieve and bring the environment accordingly. Again, when they are that big, that massive, it’s not recommended to bring up another one that big. It depends. Many people hate me for this answer, but mostly it is “It depends”.

Mike Lyles (19:27):

I think it’s a valid response because I see a lot of people struggling with that, but I’ve heard so much talk about test in production now, and thoughts from the group on that versus having your own environment for testing or staging. That’s something I’ve heard a lot of talks on… during the virus I have attended different webinars, meetups and talks on different topics. And that’s one that’s really stood out a lot. A lot of people are.. seem to be moving to test in production versus provisioning their own environments for tests. And I know there’s pros and cons to that. But thoughts on that?

Matthew Heusser (20:03):

My short answer is when you talk about testing and production, you are ignoring the very real possibility that someone will screw up an if statement or a configuration of the environment and will accidentally release a change for what’s a complex series of if statements around a complex configuration. They’ll release the wrong configuration to the wrong people, which will be error prone. And rolling it back will be a problem because they screwed up the if statements. So just turning off the configurations doesn’t do what you thought it would do. That is a real risk with some discipline, with some code review, it’s not a huge risk, but it is a problem that I’ve seen. I saw a real production environment where when you placed orders, the orders were submitted to the test system. Because of that, over the course of a year, they were basically down for a day. You have to look at the damage to reputation when that happens. So that’s the risk with testing and production.

Maya Ber Lerner (21:05):

Yeah. This topic is so, so relevant because so many people are talking about shifting right. But then again, if you look at production environment, another really important trend that we see is site reliability engineering and everything that has to do with looking at the production environment and say, “Oh, I’m going to make this the most reliable thing in the world.” So these things have to somehow work together. In site reliability engineering, you have this concept of error budgets and how much it’s okay to make mistakes and to have downtime and to have people waiting for your website to load or whatever. It has to work with that. You can do things that will kill you on that front. So I think there’s no way you can get around minimizing some of that before you release to production. Even if you do a lot of the testing in production, which I think makes sense, you need to figure out some of this that will happen beforehand. The only way to do that is automation because automation, it’s repeatable. The same thing over and over again so you don’t make all of these. There are human mistakes that cause environment drift from production.

Leandro Melendez (22:15):

Yeah. And if I could add as well to that, there are so many impacts and things that you can get a benefit with production testing practices. With this, one that I want to go back a little bit, people saying test in production and the risks. Of course, you’re not gonna only test in production. I always support switch left, switch right, stay in the middle, do them all if possible. When you are implementing some of the test in production practices, like blue-green feature toggle with this automatic environment capabilities, you can easily enable a blue-green environment to give you an example quickly, easy. Spin up the new production environment, send some of your traffic there, see how everything is doing. Do your production test trials without turning off the main one. Seeing if everything goes right, if everything survives, you won’t have a PR situation that looks bad, only a tiny a group of them. Then you say everything went well. I can send all the traffic there, turn off the past old production environment and stay with a new one that worked well. And you can do this with these automatic environment capabilities. We were talking about it as the secret weapon because it gives capabilities and cool stuff that you can do left, right, middle, up, down, whatever, more or less.

Matthew Heusser (23:45):

Thanks, man. Maya, tell us a little bit about Quali.

Maya Ber Lerner (23:48):

Well, the first thing, you know, we’re not Qualitest, we’re a different company and I’m based in New York. The company’s headquarters is in Austin, Texas, and this is where many of our people are and also the development center is in Tel Aviv, which is where I’m originally from. I actually only moved to New York three years ago. Time flies. Quali is doing Infrastructure Automation. So we kind of take Infrastructure Automation as a very technical thing. And then we add self service to it so that a lot of people can get access to Infrastructure Automation. And then we put this third really important thing on top of that, which is governance. This is becoming really important, especially as we start adopting cloud more and we become very concerned about how infrastructure is being used… actually, Matt. I just love the way you explained it. All these concerns when quality people say, “I want to own my own infrastructure and I want to automate it and I want to make it better”. All these little concerns, big concerns that come up. Who is going to make it secure? Who is going to make it compliant? Who is going to make sure that it’s cost effective? So we kind of take all these things together and we try to make that one mean lean infrastructure automation machine.

Matthew Heusser (25:00):

Cool. Great. You’ve been doing that for a long time. You were talking about infrastructure automation10 years ago.

Maya Ber Lerner (25:07):

Yeah, actually it’s kind of funny. Quali started from test automation. We have this really weird, crazy idea for 13 years ago that automation shouldn’t really be based on UI automation and clicking and recording clicks. It was a little bit progressive. At the time, people who got really excited about these ideas were people that were doing very deep infrastructure, so they didn’t have a UI to automate. So a lot of telcos and network equipment manufacturers started using our products and they came to us after doing our automation for awhile. And there was telling us, “Hey, you know, guys, test automation is not a problem at all. The problem is environments because when we start lifting the test automation percentage and the coverage, we start seeing a lot of conflicts in our static test environment”. It’s kind of funny, but this is how we actually got to doing infrastructure automation. And we’ve been doing that ever since.

Michael Larsen (26:00):

I can definitely give a thumbs up there and appreciation to that. The last “big automation thing” that I did for my group, for Socialtext was exactly that, it was more of an infrastructure automation. I think that’s probably the piece I’m most proud of doing, because I think it had the most impact for the members of our team. And yeah, there’s just these little things like going through and terraforming a system. If you use AWS or stuff like that, there’s a lot to that. Get your Docker instances to come up at the right time. Being able to actually install the code in the correct way. And it was always interesting that I’d have people that would be saying, Oh, we’ve got this problem. Oh, it’s really kind of a frustrating thing. I go, “Yeah. Did you ever use my UAT setup?” And they go, “Oh, we have that?” Like, yeah, we do. Please dig in, have fun. And they come back, “Oh, this is great. I didn’t even realize that we had this.” Thaaaaanxs.”

Maya Ber Lerner (26:54):

Yeah. Wow. You touched the problem so well. I mean, you just made the point for me, right. Automation is one piece of it and being a genius at automation is amazing. But if you can’t provide it to people, they don’t know about it. And there are only about three people in the organization that understand what you meant by terraforming or AWS or containerizing and Docker. But there are, I don’t know, 20,000 people who need environments. Right?

Michael Larsen (27:20):

Exactly.

Leandro Melendez (27:22):

Yeah. And many of those that probably still, you went through all that work to make it easy and reachable, told the people and many, one, are not aware that it’s already in their organization or two, still think it as rocket science that I need to automate a bunch of things to bring my environment and do all these things. And that’s something that I have seen as well in a few places. “”Wow. We have that, that can bring that just quickly and with a few clicks and it sounds like an infomercial, but yes you do. And we have it and someone like you, Michael, worked on it and made it available. That’s another one, make it kind of public that you can bring that and have that on your organization. It’s still a bit, not rocket science, but like, voodoo magic something hidden in too many places that it’s not that… unachievable, to call it in a way.

Michael Larsen (28:13):

Yeah. I think that’s a fair statement. I really did it just to save myself some time because I got really sick of having to go through the steps all the time and remember all the little pieces that had to move together. It struck me as interesting how many times I had to go back and remind people, “You know, I built this. It’s there for you. Why don’t you use it?” Again, it’s one of those things to where I think when we do something regularly, we maybe discount it. We don’t think about it as being that valuable. “Oh whatever. Everybody already knows about it.” And then when you realize not everybody does know about it, or you haven’t really said anything, we don’t toot our horn about it. We don’t say, “Hey, this is something that will save you time.” For me personally, I found those things helpful and very satisfying to do. I enjoy doing those kinds of projects.

Matthew Heusser (29:04):

Before we get going. I do want to talk a little bit about some of the projects we’ve got and what Michael said reminded me. I’m working on a paper for TechBeacon. It should be out not too long after this podcast. Maybe August, maybe July, that is on performance engineering. And one of my findings was the reason it seems magical is because you need multiple discipline skills to come together, to do the work. You development skills. You need system administration skills. You need devops skills. From the outside to any individual, some part of that seems like magic and you don’t know how they did it. Which goes along with what I think Michael was saying about tooting our horn. I know Mike just has a book out and… Mike Lyles… and Leandro is working on a book. Mike, tell us a little more about your book.

Mike Lyles (29:53):

So it’s called “The Drive Through is Not Always Faster”. I started this in 2002, followed some other self-help motivational writers and really made it 30 chapters, each a different story. Very easy to read. Very quick read. I released it in November of 2019, finally, after 17 years of playing around with it. It’s done really well. The virus has kind of kept me from attending bookstores and doing book signings right now. But it’s been doing very well online. It is available online right now for 99 cents in e-book format, I would love for people to try it out. I’m getting a lot of great reviews on it right now. And it’s really one of many that I’m hoping to write down the road. I’ve got another one I’m building the outline for it right now. So far, the drive through is not always faster.

Matthew Heusser (30:43):

Okay. And Leandro, you hinted before, but I don’t know much about your book.

Leandro Melendez (30:50):

Well, before… I’m going to go back a little bit to Mike Lyle’s book. I already read it, little bits of wisdom and things for your life in general. It’s a great book. The chapters are short. If you have a moment or a break, you can quickly read a chapter, get lots of wisdom. I enjoyed it, Mike, a very good book, I highly recommended it. On my end, it [my book] was born from being on load testing projects, trying to explain to customers all the little details that customers often would not understand about my trade or what had to be done. They just knew that they had to do the performance, something, something dark side. I had to come up and explain why I would do some things one way, why some another way. At one customer, I had the experience that they just allocated two or three hours for the performance tests for the whole project plan. And when I started to explain what were all the steps that we had to do on the load test, because truly they were looking for a load test, not performance. That’s another, thing that I try to clarify often on the book and they told me, well, we just schedule two hour for you and performance because we thought that you were going to come on, plug a USB, something, be done with it. And, and I was.. You can imagine my reaction at the moment. So I had to come often on projects with, I like to do examples. I like to explain things with puppies, toys, shopping centers, how cars work and do analogies and to how the performance testing and specifically load testing works. And I repeated it so much. That’s also why I started the blog and many of the things that I do publicly, I had to write these to be easy to be understood. You see, to be shareable and that I don’t have to repeat myself again and again, they are not so adapted to these new Agile days, but the book, it has a fun side. I call it the official mumbo jumbo side, where on one hand, I’m explaining everything with silly examples. And after a chapter, I put that, okay, this is the official names. This is a load test. This is a test plan. It has to have this boring thing. You have to do a scheduled meeting present it to the customer, to your client, to the project and go through these steps. I was like, I need a book as well for, to call it in a way, my people, that can read it and understand and do their work better. So the title is more or less a work in progress, but “The Hitchhiker’s Guide to Load Testing Projects” or “The FAQ and Walkthrough for a Load Testing Project”, more or less. Those are the titles that I’m working. Hope to have it out soon. I’m looking also for ways to publish it and polishing a little bit, uh, the content.

Matthew Heusser (33:48):

Where can we go to get updates so that when your book comes out, we can buy it?

Speaker 1 (33:52):

General on my social networks, I’m going to be doing noise about it as much as possible once it is ready, of course, the publishing process, finding a publisher as well and all those processes, I’m still working on them. But as soon as they are ready, all the social networks will… I’ll try to flood them with information regarding the book.

Michael Larsen (34:13):

Fantastic. And I guess. Maya, are you up to anything interesting or appearing anywhere? When I say appearing anywhere, with COVID-19 being what it is, that anywhere is probably virtual, but…

Maya Ber Lerner (34:29):

Yeah. Making only virtual appearances. I’m afraid I am the only one with no book, but I channel my writing energy to mainly… to shorter writeups. Latest. If anyone is facing accusations that their automation is risking security, then there is this blog post that explains at least five reasons why automation is actually helping security.

Michael Larsen (34:53):

Well, if it’s it’s any consolation, I don’t have a book either, but… and same story. I, you know, because of everything going on, all my appearances will be virtual as well, but I do have two coming up. In September, I will be participating with Test Guild or Automation Guild… Joe Colantonio (hey, dude!). I’m going to be speaking as part of their ongoing online conferences in regards to accessibility and testability. And I’m also, it was just recently announced that the Pacific Northwest Software Quality Conference is also going to be done virtually. And that might require some shuffling of people and who does what and where. I had originally been slated to do a similar talks on testability and accessibility. May very well still be doing that, or I may be doing something else. We will soon find out, watch this space. Uh, to everybody. I want to say, thank you so much for joining us. It’s been great having you with us and for those listening, keep your ears open. We will be back next month. And we look forward to having you listen to us again on The Testing Show. Take care everybody.

Mike Lyles (36:00):

Bye. Bye.

Maya Ber Lerner (36:01):

bye.

Leandro Melendez (36:02):

Gracias, everybody. Adios.

Matthew Heusser (36:04):

A pleasure.