 Hello, everyone. Welcome to the session from Zach. What else can we automate? You'll get very interesting tidbits from Zach. I've known him for some time, very interesting content. So really excited to hear what he has to say this time and share with us. And with that, Zach, I'm going to hand it over to you. All right. Thanks, Anand. I actually met Anand in 2018 at the Selenium Conference in Bangalore. And that was the first time I ever gave a talk in front of people. So it's good to see you again. And thanks for the introduction. And yeah, I'll get into it. So you are here for what else can we automate? How to extend your skills and constantly be learning? A little bit about me. I am a lead software development engineer in tests. I organize a Selenium meetup group in Chicago. And I've been doing events like these for like three years and five years, et cetera. Here's all my links. I'll also post these at the end of the presentation so you can follow me. So the agenda for today. Why need to constantly be learning? I mean, you're at this conference. You probably know that you need to constantly be learning. And then I'll talk about how to use rhetoric to pitch a new technological idea to your managers. That'll be the bulk of the presentation is rhetoric. And it's exciting. And at the end, we'll go over some guidelines for that new technology. Once you've won your argument, you've won the right to implement something new. So first things first, why do you need to constantly be learning? Well, it is central to being a QA engineer. I mean, you are constantly testing new things. The software you are testing is changing constantly. It's being developed constantly. And so that's literally part of your job is to be learning. But also just that in this ever evolving software landscape, you need to learn extra skills to stay relevant. As Q engineer, you wear a lot of hats and you're central to the team. So you might as well represent other interests to that team. And we all need to combat that stigma and the devaluation of software testing. Software testing is a critical role for all development work that happens. And we can combat that by gaining skills and holding our place in companies and defending testing. I also think that you need to be constantly learning on the job. I think some skills can really learn, be learned best on the job. And learning on the job makes that learning interesting because your learning is instantly applicable. And you get to practice, you know, negotiation skills to even get to work on those things. If they're not part of your core job. Yeah, jobs are really the best place to learn. You, you know, yeah, you can learn in your off hours, but the best place to learn is, you know, if you get paid while you're doing it for your core job. I also think that being, being a tester is kind of like cooking. Because like in cooking, you have a recipe and put a recipe is just a starting point. And really cooking is a learned practice. And so is testing. Testing is a learned practice where you need to constantly be upping your skills. You need to test all your ingredients as you use them. And yeah, so cooking equals testing for sure. So that's why you need to be learning. Let's talk about how to use rhetoric to convince people that you should be learning. So a lot of the rhetoric in this presentation comes from this really great book. I recommend everybody reads it by Jay Heinrichs. And I want throughout the rhetoric walkthrough these techniques, I want you to be thinking about how they can be applied to arguing for, you know, testing, visual aggression testing, security testing, accessibility testing, et cetera. How can you take these arguments, these techniques and apply them to get buy in for these technologies? And just a side note, Aristotle and talk to these ideas comes in three. A lot of these ideas are older ideas, you know, Grecian ideas, Roman ideas, and they come in threes. It's pretty unique. All right. So let's describe a pitch. When you're pitching a new technology, well pitches in general work best in threes, you know, you want to stimulate the audience's emotions, change their opinion about something and get them to act on something. Arguments in a few words are kind of a form of seduction. So you should start off usually with a story or something that appeals to someone's emotions that kind of seduces them into the idea that you're proposing. And your success rate will go up drastically when pitching a new idea if you leave with something that affects emotions. It could be as simple as asking someone how their day was or about their weekends or building rapport. It could be mentioning a hot button item at work. Mention there was a big hit to the revenue for X, Y and Z reason. You know, launch into a story that hits on those emotional buttons so that you can go into the next topic and change their opinion and get them to do other things. So when you're changing the audience's opinion, in this case, you're changing their opinion that these technologies aren't superfluous. They're worth POCing. They're the kinds of things that it's worth it to prevent these things and have an automated solution to prevent them. So you want the audience to get the sign off that POCing, that technology is worth it. So there are three methods of persuasion kind of throughout those three steps. Those are the logos, the ethos and the pathos. And so you could say the stimulating the audience's emotions. I mean, that's a probably an ethos or a pathos kind of argument. When you're changing their opinion, you employ a lot of logos techniques, a lot of logical techniques to get to their change their opinion, but you can also employ the other two techniques. Basically, these three techniques are interwoven in all all the three steps. And I didn't mention it last slide, but I do have these beautiful Roman sculptures and background of each slide. So pay attention to those. So I described those kind of three methods of persuasion. There's also three tenses of arguments that can be applied arguments. So there's the forensic argument. It's concerned blame it takes place mostly in the past tense, you know, we could have prevented that bug if we had this testing in place. So that's, you know, looking at the past. Demonstrative argument. We want this test to exist to identify with our values of uptime and stability, you know, those are our current values and that would be an argument that that aligns with that. And then deliverative arguments are, you know, prescriptive they take place in the future. This technology will save us x dollars it'll prevent x amount of bugs it'll prevent this amount of security breaches and something that the Red Red editions tell us is that future arguments are often the strongest arguments because they appeal to your sense of looking forward and they're most positive, as opposed to, I mean forensic arguments can work it really depends on the person that you're dealing with but but they do recommend going with future arguments. That is a good tense to have an argument in. And, you know, you need to find the proper tense that works with your audience. What you can do is you can move tenses from one from the past and then reconfigure it to the present or the future and that that's another good technique. All right, let's talk about the idea of concession. Concession is when you agree with an opponent's points but still you're still controlling the argument. And it's about the best way to handle doing concession because every argument has concession points because that's how you know arguments happen with the exchanges with others, and you'll the best way to do it is to shift the discussion to definitions of terms and values when you're attacked. So if someone says, you know, we experienced a regression, you didn't do enough testing, you didn't test the right things, we need to be testing the right things. When you bring up bringing up one of these technologies, you know, you may feel attacked in that moment, but you can you can then agree and concede, but then you can move it to a discussion of values. Like what what do we actually do are the right things to test. What can we prevent this from happening in the future, what can we automate to make this not happen again to align with our values of stability. So again, I'm framing that that negative that forensic argument into a value argument and just defining the terms, the term being like, what do we deem are the right things to test. So, when, when you're having concessions try to get that argument to the future. And then you'll notice that I conceded and I started stopped giving descriptions of these aggression busts because that's annoying. I actually got bored of it when I was making this presentation. So, this will be the future bust in the presentation. I wanted to warn against the kind of concession that we shouldn't use. And a lot of blogs might tell you that when you're presenting how to solve a problem put your preferred solution in the middle. And for example, like let's say there's a security breach, and you're like, alright, we have three options do nothing, build a security suite, or pay all this money for penetration testers. And since you put yours in the middle, I mean, it's, it's, it's cliche, you know, people will see through it. They'll see through that tactic and I think that concessions work in a more of a human manner. And like a one on one conversation, I wouldn't use this kind of three framing of a solution to put yours in the middle. It's kind of overblown. So, another really important part of negotiation is knowing your audience. And you want to match your language to your audience. If you're dealing with with the product. You can mention these kinds of terms, because those are the terms that they deal in and then you'll be able to identify with your audience. And if the audience if a product person is incredibly end user driven, I mean, you can use terms like user experience. And you can construct arguments that will reflect how the end user will feel and that will apply more to that product person because that's something that they empathize with. Same, like if you're talking to engineering managers, maybe, you know, code coverage, developer experience pipelines, those are terms that that work with them. So, so use that kind of language. When you're creating arguments, and you're having these negotiations with your managers, be aware of faulty kinds of reasoning and I'm going to go over the kind of five really common kinds of faulty reasoning. And that'll be the next five slides. So, a false comparison. Basically, because one part of something is one way the whole thing is that way, for example, if you see all natural and food label, that's probably because there's one item in that product that is natural. So they just say that it's all natural, because that one item and that's, I mean, not strictly true to the informed consumer. And, you know, when you're talking about security testing, maybe your manager says, we don't need secure or sorry, not security testing when you're talking about load testing, maybe your manager will say something like since the app desk, app decks for the app is high, you know, all APIs are stable, we have a really good app decks. But the thing is, is that this is an aggregate metric so it's not, you can still have issues with apis in an individual level. And that wouldn't show in this metric. So, make sure you know do your research about the arguments that are being made with regards to these testing technologies. So, the fallacy, the antecedent, that's assuming that because something worked in the past, it will continue to work in the future. You know, I don't need to slow down. I haven't had an accident yet. That's, you know, not strictly true. You can easily have accidents in the future. I don't need visual regression testing frameworks. I haven't had a visual regression test yet. Well, you could. And, you know, having a framework in place will prevent it. So, let's be aware of that kind of thing. All right, the false choice. This is a fun one. It's commonly like kind of pollsters use this technique where they put many questions side by side. And so, like, do you support government finance abortions and a woman's right to choose? I mean, those are actually different issues. They're interrelated for sure. But they can be thought of different aspects of a similar issue. And one can agree with one and not the other and they don't need to go together. And it's, it doesn't need to be a choice like that. You know, do you need acceptance testing to see if everything looks right and an expensive visual regression automated testing to verify the same thing. And it truly like they do different things. Acceptance testing, you know, does a ton of different things and visual aggression testing does one thing specifically really well. And they're both related to quality, but they, they do it in a different way. So I wouldn't say that they're equal choices. It's like five minutes. Thank you. All right. I think my time is good. So, so this is the fourth one, the wrong ending. So that's extrapolating a false conclusion from the evidence you're given another version of it's the slippery slope. So, you know, if we pull out of the war now or all our soldiers have died in vain and yeah, that's a slippery slope and in terms of arguments. And, you know, an analog to that is, you know, is if this new framework works engineers are going to want to upgrade like they're going to want to spend entire sprints on technical depth they're going to want to do all the tech debt things. And I mean it's not true. One does not equal the other doing a small piece of tech tech doesn't mean that you have to do all the tech debt. Last fallacy is the right way in the wrong way. And basically, you know, avoid that kind of argument style, it prevents further conversation and the other side might not feel heard or the views are taken into consideration so don't just say you know, do the security testing because it's the right way to develop software. I mean that doesn't go anywhere. So avoid that tactic. Use negotiations make sure to pick the best format emails and epic documents favored logic slack and instant messaging favors pathos, which is your emotion. Yeah, slackness messaging or very emotional platforms. So if you're kind of if you're making an emotional argument to a target that works with emotion slack might be the best format for that. And I think that in person or video chat favours it those are the character you can you can use you can be charismatic. You can use your character to convince them of that thing. So, and obviously you can use a mix of these different things but it's kind of cool to notice how the different mediums have different characteristics like this. So when you have your argument, use data bring up pain points, quantify them hours dollars reputation etc have a benchmark to compare to have a plan to measure the effort set metrics, etc. These are kind of the that logos to bring to your argument. So I have a little time so I can go run through an argument for a visual regression testing framework for adopting that at your company so just as an example we're going to stimulate the audience motion so we're going to tell a story. Maybe this story is about a response button on a website and the end user can complete their workflow and they logged off in frustration because of a visual regression. You know, they're, they're so used to that workflow so when the button moved they couldn't complete their workflow. Now, after that I'm going to try to change the audience's opinion on visual regression technology I'm going to say it's easy to implement cheaper than I thought. They might say it doesn't align with our values because we value to move fast and break things. So like why do we need this framework that will tell us that we're breaking things and I'll point out that that's a false choice argument. Because you can value moving fast and not like just implementing a visual regression test doesn't mean you're not going to break things it just means you're not going to break significant things in a significant way. So you point that out. You can then get the audience to do or choose something and that would be, you know, implementing a free tier to at least prevent the respond button bug from happening I'm not talking about implementing visual regression testing for the entire, for the entire application, just a small part. And it'll be free and then I get to learn a new skill, which is visual regression testing. Voila argument made. So there's an accessibility testing one in here too I'm not going to go over it because we're running out of time. There's some just common stories that, you know, are for that furthest part of the argument that you could use. And, but really when when you're trying to find stories you can find them, you know, blogs conferences meetups meetups are conferences like this are a great place to get stories so that you can go back to your companies and, and recant those stories for why you need to implement technologies, definitely reach out to your peers for those horror stories. And then finally, implement that new testing technology get it into a pipeline as he get the PSE in front of all you can make it easy to contribute to make it people make it easy for people to comprehend comprehend what's going on, set of time to reevaluate is it adding enough value do we still wanted to use it who's responsible make sure there's a point person will kind of insertion our place could there be more is it instilling that quality that you promised. And there are some basic challenges to implementing a new technology that everybody's going to experience. And those are, it will take a bit of time to develop at first, and it won't have much coverage at first. And you will need to learn the hard lessons of that new type of technology. Every technology is not as simple as it's read me, and it's introduction and it's getting started. There always are hard lessons to learn about that technology. And yeah, you might have to learn them but give yourself some wiggle room when you're implementing it so that those hard lessons can be learned and then you can iterate and make it more rich. And then you can also set a service liability agreement for yourself and how long that entire test suite takes to run, and to develop and execute so that you're not wasting your time and the expectations are clear, because that's the best thing. When you're arguing for these technologies is make sure your expectations are clear and what they will deliver and what they won't deliver, don't over promise and under deliver. And that's the presentation. I would love to talk about these topics in detail after in the Hangout, and here's where to find me. And that's the presentation. Thank you. Thank you so much, Zach. And again, for those who don't know Zach has got up really early in the morning to help to join us and share his thoughts with us. Very interesting techniques for sure. And the way the presentation style also really enjoyed that. Thanks Zach. Thanks Anand.