Screaming in the Cloud - The Mythos of Testing with Angie Jones

Episode Date: September 7, 2021

About Angie Angie Jones is a Java Champion and Senior Director who specializes in test automation strategies and techniques. She shares her wealth of knowledge by speaking and teaching at software conferences all over the world, writing tutorials and technical articles on angiejones.tech, and leading the online learning platform, Test Automation University.As a Master Inventor, Angie is known for her innovative and out-of-the-box thinking style  which has resulted in more than 25 patented inventions in the US and China. In her spare time, Angie volunteers with Black Girls Code to teach coding workshops to young girls in an effort to attract more women and minorities to tech.Links:Applitools: https://applitools.comBlack Girls Code: https://www.blackgirlscode.comTest Automation University: https://testautomationu.applitools.comPersonal website: https://angiejones.techTwitter: https://twitter.com/techgirl1908

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. route machine data from anywhere to anywhere. Simple, right? As a nice bonus, it helps you not only improve visibility into what the hell's going on, but also helps you save money almost by accident. Kind of like not putting a whole bunch of vowels and other letters that would be easier

to spell into a company name. To learn more, visit Cribble.io. That's C-R-I-B-L dot I-O. And tell them Corey sent you, and wait for the wince. This episode is sponsored in part by Thinkst Canary. This might take a little bit to explain, so bear with me. I linked against an early version of their tool, CanaryTokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, or anything else like that that you can generate in various parts of your environment, wherever you want them to live. It gives you fake AWS API credentials, for example. And the only thing that these are

empowered to do is alert you whenever someone attempts to use them. It's an awesome approach to detecting breaches. I've used something similar for years myself before I found them. Check them out. But wait, there's more, because they also have an enterprise option that you should be very much aware of. Canary.tools. Take a look at this. What it does is provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even get a physical device that hangs out on your network and impersonates whatever

you want it to. Whenever it gets NMAP scanned or someone attempts to log into it or access files that it presents on a fake file store, you get instant alerts. It's awesome. If you don't do something like this, instead, you're likely to find out you've gotten breached the very hard way. So check it out. It's one of those few things that I can look at

and say, this is an amazing idea. I am so glad I found them. I love it. Again, those URLs are canarytokens.org and canary.tools. And the first one's free because of course it is. The second one is enterprising. You'll know which one of those you fall into.

Take a look. I'm a big fan. More to come from Thinkst Canary in the weeks ahead. Welcome to Screaming in the Cloud. I'm Corey Quinn. If there's one thing that I have never gotten the hang of, it's testing. Normally, I just whack the deploy button, throw it out into the general ecosystem, and my monitoring system is usually called customers. And if I don't want to hear from them, I just stop answering calls from the support desk. Apparently, that is no longer state-of-the-art because it's been about 15 years. Here to talk about testing from a more responsible direction is Angie Jones, a senior director and developer at Applitools. Thanks for joining me. Hey, Corey. I am cracking up at your confession there, and I appreciate it because you're not unique in that story. I find that a lot of engineers

follow that same trend. There are things we talk about, and there are the things that we really do instead. We see it all over the place. We talk about infrastructure as code, but everyone clicks around for a few things in the cloud console, for example, and so on and so forth. We all know we should, in theory, be doing things, but expediency tends to win the day. And for better or worse, talking about testing, in many cases, makes some of us feel better about not actually doing testing. And one of these days, it's one of those, I really should learn how TDD would work in an approach like this, but my primary language has always been, well, always been a crappy version of whatever I'm using. But for the last few years, it's been Python. There are whole testing

frameworks around all of these things, but I feel like it requires me to actually have good programming practices to begin with, which let's be very clear here, I most assuredly don't. That's a fair assessment, but I would also argue, you know, in cases like those, you need testing even more, right? You need something to cover your butt. So like, what are you doing? You're just kind of living on the edge here? Sort of. In my case, it's always been that I'll bring in an actual developer who knows what they're doing to turn some of my early scripts into actual tools. And the first question is, okay, can you explain what this is doing for me? Great. So we're going to throw it away and completely replace it. So what are the inputs?

What are the outputs? And do you want me to preserve the bugs or not? At which point, it's great. It's more or less like I'm inviting someone to come in and just savage my code, which is apparently also a best practice. But for better or worse, I never really thought of myself as an engineer, so it's one of those areas where it doesn't cut to the core of my identity

in any particular way. I do know it would be nice that, oh yeah, when I wind up doing an iterative deployment of a Lambda function or something, and it takes five minutes to get updated, and then I forgot to put a comma in or something ridiculous like that. Yeah, it would have been nice to have something that, you know, a pre-commit hook that caught something like that. Yeah, yeah. It's interesting you said, maybe one of these days I'll learn. And that's the issue I find. No matter what route you took to learn how to become whatever

you are, software engineer, whatever, testing likely wasn't part of that curriculum, right? So we focus when teaching very heavily on teaching you how to code and how to build something, but very little, if any, on how to ensure you built the right thing and that it stands the test of time. My approach has always been, well, time to write some code. And it started off as just as a grumpy systems administrator. It was always shell scripts, which, okay, great. Instead of doing this thing on 15 machines, run a for loop and just iterate through them. And in time, you start inheriting other people's crappy tooling. And well, I could rewrite the entire thing in a week and a half, or I could figure out just enough Perl to change that one line in there. And that's how they get you. You sort of stumbled your way

into it in that direction. Naive questions I always like to ask around testing that never really get answers for, because I don't think to ask these when other people are in the room, and it's not two o'clock in the morning and the power's gone out. You have the basic linter test of do you have basic syntax errors in the code? Will it run seems to be a sort of baseline, easy acceptance test. But then you get into higher level testing of unit tests, integration tests, and a bunch of others I'm sure I'm glossing over because I, to be direct, I tend to conflate all these in my head. What is the hierarchy of testing if there is such a thing? Yeah. So Mike Cohn actually created a model that

is very heavily used within the industry and it's called the test automation pyramid. And what this model suggests is that you have your unit tests, you have some kind of like integration type tests in the middle, and then you have these end-to-end tests on top. So think of like a pyramid divided into three sections, but that's not divided equally, right? The largest part of that pyramid, which is the base, is the unit test so this suggests that the bulk of your test suite should comprise of unit tests right the idea here is that these are very small they're very targeted meaning they're easier to write they take less time to run. And if you have an error, it kind of pinpoints exactly what's

wrong in the system. So these are great. The next level would be your integration. So now how do two units integrate together, right? So you can test this layer multiple different ways. It might be with APIs, it might be the business logic itself, calling into functions or something like that. And this one is smaller than the unit test, but not as large as the final part, which is the end-to-end test. And that one is your smallest piece. And it doesn't even have to be end-to-end. It could be UI, actually. That's how it's labeled by Mike Cohn in his book. UI tests. So the UI tests, these are going to be your most fragile tests. These are going to take the most time to write as well as the most time to execute.

If something goes wrong, you have to dig down, you know, to figure out what exactly broke to make this happen. So this should be the smallest chunk of your overall testing strategy. People far smarter than I have said that in many cases, at a long enough axis, testing and monitoring or observability, which is apparently a term for hipster monitoring, are aligned on the same axis. In the olden days of systems administration, you can ping the machine and it responds just fine, but the only thing that's left on that crashed machine is just enough of the network stack to return a ping. So everything except the thing that tells you it's fine is in

fact broken. So as you wind up building more and more sophisticated applications, the idea being that the testing and the is everything all right monitoring ping tends to more or less coalesce into the same thing. Is that accurate from your view of the world? Is that something that is an oversimplification of something much more nuanced? Or did I completely misunderstand what they were saying? Which is perfectly possible. You kind of lost me somewhere in the middle, so I'm just going to nod and say yes. No, no. The hard part that I've always found is I lie to myself when I'm writing code. Oh, I don't need to write a unit test for this because I've gotten it working. I tested it with something that I know is good. It returns what I expect. I test it with something bad and

well, some undefined behavior happens because that's a normal thing to happen with code. And great. I don't need to have a test for that because I've already gotten it working, problem solved. It's a great lie. And then I make a change later on that in fact does break it. It's the, but I'm writing this code once. Why would I ever go back to this code and write it again? It's just a quick and dirty patch

that only needs to exist for a couple of weeks. Yeah, the to-do, remove this later. And that code segment winds up being load-bearing decades into the future. Like, yeah, one of these days someone's going to go back and clean up all of my code for me. Like, the code fairies are going to come in the middle of the night with the elves and tidy everything up. I would love to hire those mythical creatures, but can't find them. This mythical sprint where it's, oh, it's only clean up this entire sprint. You know, everybody's kind of holding out and waiting for that. But no, you hit the nail on the head with the reason why you need

to automate your tests essentially, right? So I find a lot of newer folks to the space. They really don't understand why on earth would I spend time like writing code to represent this test? Just like you said, I implemented the feature. I tried it out. It worked, you know, and Hey, I even tried a non happy path. And when it broke, I had a nice little error message to tell the user what to do. And they feel really good about that. So they can't understand like, why would I invest the user, what to do, and they feel really good about that. So they can't understand like, why would I invest the time, which I don't have, to write some tests? The reason for that is just as you said, this is for regression, right? Unless that's the end of this application and you're not going to touch it ever again for any reason, then you need to write some tests because you're going to constantly change

the application, whether that be refactoring, whether that be adding new features to it, it's going to change in some way. And you cannot be sure that the test of yesterday still worked today because whenever you make the change, you're just going to kind of poke around manually at that little area, not realizing there could be some integration things that you totally screwed up here, and you miss that until it goes out into prod. The worst developer I've ever met, hands down, was me, six months before I'm looking at whatever it is that I've written. And given that I do a lot of my stuff in a vacuum, and I'm the only person to ever touch these repositories, I could run git blame, but I already know exactly what it's going to tell me.

So we're just going to skip that part. Like it's a test. And yeah, we're just going to try and fix that and never speak about it again. But I can't count the number of times I have looked at code that I've written. And I do mean written, not blindly copy and paste it out of Stack Overflow, but actually wrote. And at the time I understood exactly what it did. And then I look at it and it is what on earth was I thinking? It technically doesn't even return anything. It can't be doing anything. I can just remove that piece entirely and the whole thing breaks. I've out-clevered myself in many respects. And I love the idea, the vision, that testing would catch these things

as I'm making those changes, but then I never do it. It's getting started down that path and developing a more nuanced and, dare I say, formal understanding of the art and science of software development. Always feels like the sort of thing I'll get to one of these days, but never actually got around to. Nowadays, my testing strategy is to just actually deploy things into someone else's account and hope for the best. And oh, good. Well, everyone has a test account. Ideally,

it's not their own production account. And then we start to expand on beyond that. You have come to this from a very different direction in a number of different ways. You are, among other things, a Java champion, which makes it sound like you fought the final boss at the end of the developer internet. And they sound really hard. What is a Java champion? Yeah. So a Java champion is essentially an influencer in the Java ecosystem. Can't just call yourself this. Like you say, you got to fight the guy at the end, you know. But seriously, in order to become one, current Java champion has to nominate you. And all of the other Java champions has to review your package, basically looking at your work.

What have you contributed to the developer community in terms of Java? So I've done a number of courses that I've taught. I've taught at the university level as well. I am always talking about testing and using Java, you know, to show how to do that, as well as, you know, talks and all of this stuff. So apparently I had enough for folks to vote me in. So it is an organization that's kind of ordained

by Oracle, the gods of Java. So it's a great accomplishment for me. I'm extremely happy about it. And just so happened to be the first black woman to become a Java champion. So the news made a kind of big deal about that. Congratulations. Anytime you wind up getting that level of recognition in any given ecosystem, it's something to stop and take note of. But that's compounded by just the sheer scale

and scope of the Java community as a whole. Every big tech company I know has inordinate amounts of Java scattered throughout their infrastructure. A lot of their core services are written in Java, which makes me feel increasingly strange for not really knowing anything about it other than that it's big and that there are this entire ecosystem of IDEs and frameworks and ways to approach these things that it feels like those of us playing around in crappy bash scripting land have the exact opposite experience of, oh, I'm just going to fire up an empty page and fill it with a bunch of weird commands and run it and it fails and run it again and it fails and it finally succeeds when I fix all the syntax errors and that's great. It feels like there is a much more

structured approach to writing Java compared to other languages, be they scripts or full-on languages? Yeah, that's been a gift and a curse of the language, right? So as newer frameworks have come out, or even as JavaScript has made its way to the front of the line, people start looking at Java as kind of bloated and all of these rules and structures were in place, but that feels like boilerplate stuff and cumbersome in today's development space. So fortunately, the powers that be have been doing a lot of changes in Java. We went for quite a while where releases were about

every three years or so, and now they've committed to releases every six months. So most people are on Java 8 still, but we're actually at like Java 16 now, right? So now it's kind of hard to keep up, but that makes it fun as well. There's all of these newer features and new capabilities. And now you can even do functional programming in Java. So it's pretty nice. Question I have is, does testing lend itself more easily to Java versus other language? And I promise I'm not trying to start a language war here. I just know that, well, how do I effectively

test my Python code leads to a whole bunch of, well, it depends. It's like asking an attorney any question on the planet. Same story. Like, well, it really depends on a whole bunch of things. Is it a clearer, more structured path in Java, or is it still the same murky, there are 15 different ways to do it, whichever one you pick, there's a whole cacophony of folks telling you you've done it wrong? Yeah, that's a very interesting question. I haven't dug into that deep, but Java is by far the most popular programming language for UI test automation. And I wonder why that is,

because you don't use Java for building front end, right? You use JavaScript. I don't know how this came, well, I do know how it came to be. Like back in the day, when we first started kind of doing test automation, JavaScript was a joke, right? People would laugh at you if you said that you were going to use JavaScript as, you know, I'm going to learn JavaScript and try to like enter the workforce. So, you know, that was a big no-no and kind of a joke back then. So Java was what a lot of your developers were using, even if they were only using it for the backend, maybe. You didn't really have a need of language on the client side back then, right? You had your PHP on the backend. You just did some HTML and some CSS on the front end, you know, so there wasn't a whole lot of scripting

going on back then. So Java was the language that people chose to use. And so there's a whole community out there for Java and testing. Like the libraries are very mature. There's, you know, open source products and things like this. So this is by far the most popular language that people use, no matter what their application is built in. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of hello world demos,

allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept

testing without spending a dime. You know that I always like to put asterisk next to the word free. This is actually free. No asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. If I were looking to get a job in enterprise these days, it feels like Java's the direction to go in with the counterpoint that, let's say that I go through the path that I went through. I don't have a college degree. I don't have a high school diploma. If I were to start out trying to be a software engineer today or advising someone to do the same, it feels like the lingua franca of everything today seems to

be JavaScript in many different respects. It does front-end, it does back-end, people love to complain about it, so you know it's valid. To be clear, I find myself befuddled every time I pick it up. I'm not coming at this from a JavaScript fanboy perspective in any respect. The asynchronous execution flow always messes with my head and leads to more questions than answers. Is that assessment, though, of starting languages accurate? Are there cases where Java is absolutely the right answer as far as what to learn first? Yeah. So I first started with C++, and then I learned Java, right? But what I find is Java, because it's so strict, it's a statically typed language, and there's lots of rules, and you really need to understand paradigms and stuff like that with this language. It's harder to learn, but once you learn it, you know, it's much easier to pick up other languages, even if they're dynamically typed, you know.

So that's been my experience with this. As far as jobs. So the last time I looked at this, someone did some research and wrote it up. This was 2019. And they looked at the job openings available at the time. And they, you know, divided it by language. And Java was at like 65,000 jobs open. Python was a close second with 62,000. And JavaScript was third place with 39,000.

So quite a big difference. But if you looked at tech Twitter, you think like JavaScript is all there is, right? Most of my followers and folks that I follow are JavaScript folks, front end folks. So it is a language I think you definitely need to learn, you know, it's becoming more and more prevalent. If you're going to do any sort of like web app, you definitely want to kind of know it. So I'm definitely not saying, oh, just learn Java and that's it. I think there's definitely a need for adding JavaScript to your repertoire.

But Java, there does seem to be more jobs, especially the big enterprise type jobs in Java. The reason I ask so much about some of the early stage stuff is that in your spare time, which it sounds like you have so much of these days, you volunteer with Black Girls Code to help teach coding workshops to young girls in an effort to attract more women and minorities to tech, which is phenomenal. A few years ago, I was a volunteer instructor for Year Up before people realized, oh, maybe having an instructor who teaches by counterexample isn't necessarily the best approach of teaching folks who are new to the space. But the curriculum I was given for teaching people how Linux worked

and how to build web servers and the rest started off with a three-day module on how to use VI, an arcane text editor that no one understands. And the only reason we use it is because we don't know how to quit it. And that's great and all, but I'm looking at this and my immediate impression was we're scrapping that, replacing it with nano, which is basically what you see is what you get. And it's something that everyone can understand and appreciate without three days of training. And it felt an awful lot like we're teaching people VI almost as a form of gatekeeping. I'm curious, when you presumably go down the path of teaching people who are brand new to this space, how do you wind up presenting testing as something that they should start

with? Because it feels like a thing you have to know first before you can start building anything at scale, but it resonates on some level with feeling like it's a, ah, you must be able to learn this religion first, then you'll be able to go and proceed further. How do you square that circle? Yeah, so I had the privilege of being an adjunct professor at a college and I taught Java programming to freshmen, right? This was really interesting because there's so much to teach and this is true of all the courses. So when I say that they don't include it in a curriculum, that's not really that much of a slight on them. Like it's just so much you have to cover. Right. So I, me, the testing guru, I still couldn't find space to devote like an entire sitting a chapter or

whatever on testing. So I kind of wove it into my teaching style. So I would just teach the concept. Let's say I'm teaching loops today, right? And I'll have a little exercise that you do in class. So we do things together. And then I say, okay, now you try it by yourself. Here's a problem. Call me over when you're done. And as they would call me over when they're done, I would break it. I would break their code, right? I do some input that they weren't expecting and all of a sudden it's broken. And they started expecting me to do this. She's going to come and she's going to break my stuff, right? So they start thinking themselves, let me test it before I give it to my user who is

Professor Angie or whatever. So that's how I kind of taught them that. Same with homework assignments. So they would submit it. I would treat it like a code review, go through line by line. I didn't have any automated systems to test their homework assignments. I did like a code review, you know, gave them feedback on how to improve their style, but also I would try to break it and give them, here's all the areas that you didn't think of, right? So that was my way of teaching them that quality matters and how to think about beyond the requirement, right? The requirement is going to say, someone needs to be able to log in. It's not going to give you all of the things that should happen, you know, if there's a wrong password. So these are things as an engineer, you need to think beyond that one line requirement that you got and realize that this is part of it

as well. So it's almost a matter of giving people context beyond just the writing of the code, which frankly seems to be something that's been missing from many aspects of engineering culture for a while. The understanding the people involved, understanding that it is not just you or your department or even your company in some cases. Exactly. And I tried to stress that very heavily in each lecture. Who is your end user? And your end user cannot see your code. They cannot see your comments in the code that's telling them, make sure you input it this way or whatever. Like none of that is seen. So you have to be very explicit in your messages and your intent and behavior with the end user. One last area I wanted to cover with you

when I was doing some research on you before the show is that you are an IBM master inventor, which I had no idea what that was. Is that a term of art? Let me Google it. And it turns out that you have, according to LinkedIn at least, 27 patents in your name. And it's, oh, yeah, it's one of those areas where you look at something like, what gives someone the hubris to call themselves, or the grounds to call themselves that? And, oh, yeah, oh, they're super accomplished, and they have a demonstrated track record of inventing things that are substantial and meaningful. I guess that would do it. I'd never heard the term until now. What is that? And how

are you the prolific, for lack of a better term? Yeah. So I used to work at IBM, and they're really big on innovation. And I haven't kept track in a while but for many many years they were like number one you know producer of patents if this year or whatever so it was kind of in the culture to innovate now I will say like a very small percentage of people employees there would take it as far as I did to actually go and patent something. Oh, it's a don't offer if you're not serious model. But I mean, it was there. It was a program there where, hey, you got an idea for a software patent, write it up.

We'll have our lawyers, our IP lawyers review it. And then they'll take your little one page doc and turn it into a 25 page legal document that we submit to the USPTO, United States Patent Trademark Office, who then reviews it and decides if this is novel enough and grants it or dismisses it. And hey, we'll pay you for these patents. We'll pay for the whole process. And so I thought, heck, why not? And I kind of got hooked. So it just so happens I got a lot of good ideas and I would collaborate with people from other areas of the business. And it was an excellent way for me to kind of learn about new technologies. If something

new was coming out, I would jump on that to kind of explore, play with it and think about, are there any problems that this technology is not aimed to solve? But if I tweak it in some way, or if I integrate it with some other concept or some other technology, do I get something unique and novel here? And it got to the point where I just started kind of walking through life. And as I'm hit with problems, like I'll give you an example, I'm in the grocery store, right? And this inevitably happens to everyone. What? You choose the wrong line in the grocery store, right? This one looks like it's moving. I'm going to go here. And then the whole time you're looking to your right and

that line is moving, right? And you're like stuck every time. So it got to the point where I started recognizing when I'm frustrated and say, this is a problem. How can I use tech to solve this? And so in that problem, I came up with this solution of how I could be able to tell which one of these is the right line to get into. And that consisted of lots of things like scanning the things in everyone's cart or your car. You have these smart carts that kind of know what's inside of them, polling the customer's spending or their behavior, right? So are they going to come up here and send the clerk back to go get cigarettes or alcohol, or are they going to pull out 50 coupons? Are they going to write a check, which takes longer? So kind of

factoring in all of these habitual behaviors and what's in your cart right now and determining overall processing time. And that way, if you display that over each queue, you know which one would be the fastest to get into. So things like that is what I started kind of doing and patenting. Well, my favorite part of that story is that it is clearly a deeply technical insight into this, but you told the story in a way that someone who is not themselves deeply technical can wrap their heads around. And I just making sure you're aware of exactly how rare and valuable that particular skill set is. So often there are people who are so in love with a technology that they cannot explain to another living soul who is not equally in love with that technology. That alone is one of the biggest reasons I wanted to

have you on this show, was your repeated demonstrated ability to explain complex things simply in a way that I know, this is anathema for the tech industry that is not condescending. I come away feeling I understand what you are talking about now. Thank you so much. That is one of the skills I pride myself on when I give talks. I want everyone in that room to understand it, even if they're not technical. And lots of times I've had comments from anyone from like the janitor to the folks who are working AV who they don't work with computers or anything at all. And they've come to me after these talks like, okay, I heard a lot of talks in here. Everybody is over my head. I understood everything you said.

Thank you. And yet it's still beneficial to those who are deeply technical as well. So thank you so much for that. No, it's a very valuable thing and it's what I look for the most. In fact, my last question for you is tying around that exact thing. You have convinced me. I want to learn more about test automation and learn how this works with an eye toward

possibly one day applying it to some of my crappy nonsense that I'm writing. Other than going on Google and typing in a variety of search terms that will lead me to probably a Stack Overflow thread that has been closed as off-topic but still left up to pollute Google search results, where should I go? Yeah. So I've actually started an entire university devoted to testing. And it's called Test Automation University. And I got my employer, Applitools, to sponsor this. So all of the courses are free and they involved in going through their material and making sure that it's correct and accurate. So the courses are of top quality. We have about a little over 85,000

students at Test Automation University. So you definitely need to become one if you want to learn more about testing. And we cover all of the languages. So Java, JavaScript, Python, Ruby. We have all of the frameworks. We have things around mobile testing, UI testing, unit testing, API testing. So whatever it is that you need, we got you covered. You also go further than that. You don't just break it down by language. You break it down by use case. If I look at Python, for example, you've got a web UI path. You've got an API path. You've got a mobile path. It aligns not just with the language, but with the use case in many respects. I'm really glad I asked that question. We will, of course, include a link to that in the show notes. Thank you so much for taking the time to speak with me. If people want to learn more other than going to Test Automation University, where can they find you?

So my website is angiejones.tech, T-E-C-H, and I blog about test automation strategies and techniques there. So lots of good info there. I also keep my calendar of events there. So if you wanted to hear me speak or one of my talks, you can find that information there. And I live on Twitter. So definitely give me a follow. It's techgirl1908. And we will, of course, include links to all of that. Thank you so much for being so generous with your time and insight.

I really appreciate it. Yeah, thank you so much for having so generous with your time and insight. I really appreciate it. Yeah, thank you so much for having me. This was fun. Angie Jones, Java champion and senior director at Appla Tools. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform

of choice, along with a long, ranting, incoherent comment that fails to save because someone on that platform failed to write a test. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

This has been a HumblePod production. Stay humble.