Transcript
Announcer: 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.

Corey: This episode is sponsored in part by CircleCI. CircleCI is the leading platform for software innovation at scale. With intelligent automation and delivery tools, more than 25,000 engineering organizations worldwide—including most of the ones that you’ve heard of—are using CircleCI to radically reduce the time from idea to execution to—if you were Google—deprecating the entire product. Check out CircleCI and stop trying to build these things yourself from scratch, when people are solving this problem better than you are internally. I promise. To learn more, visit circleci.com.

Corey: This episode is sponsored in part by Thinkst. This is going to take a minute 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, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. If there’s one thing that I have never gotten the hang of, its 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 stopped 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.

Angie: Hey, Corey. [laugh]. 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 [laugh] follow that same trend.

Corey: 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 doubt.

Angie: [laugh]. That’s a fair assessment, but I would also argue, in cases like those, you need testing even more, right? You need something to cover your butt. So, what are you doing? You’re just, kind of, living on the edge here?

Corey: Sort of. In my case, it’s always been that I’ll bring in an actual developer who knows what they’re doing to—

Angie: Ah.

Corey: —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 with—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’ve never really thought of myself as an engineer, so it’s one of those areas where it’s 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, if it takes five minutes to get updated, and then I forgot to put a comma in or something ridiculous like that. Yeah. Would have been nice to have something—you know, a pre-commit hook—that caught something like that.

Angie: Yeah, yeah. It’s interesting. You said, “Well, 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.

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.

Corey: 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 upon 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 and 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 is gone out.

You have a 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—to be direct—I tend to conflate all these in my head. What is the hierarchy of testing if there is such a thing?

Angie: 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 a pyramid divided into three sections. But that’s not divided equally; 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.

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? So, you can test this layer multiple different ways: it might be with APIs, it might be the business logic itself, you know, 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 to figure out what exactly broke to make this happen. So, this should be the smallest chunk of your overall testing strategy.

Corey: People far smarter than I have said that in many cases—along with access—testing, and monitoring—or observability, which is apparently a term for hipster monitoring—are lying on the same axis. Where 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?

Angie: You kind of lost me somewhere in the middle. So, I’m just going to nod and say yes. [laugh].

Corey: [laugh]. No, no, it—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’d gotten it working, I tested it with something that I know is good, it returns what I expect; I tested 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 got it working. Problem solved.

Angie: Right. Right.

Corey: It’s a great lie.

Angie: Yeah.

Corey: And then I make a change later on that, in fact, does break it. It’s the, “But I’m writing this code once and 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 todo: remove this later, and that code segment winds up being load-bearing decades into the future. I’m 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.

Angie: This mythical sprint, where it’s, “Oh, let’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. So, I find a lot of newer folks to the space, they really don’t understand, why on earth would I spend time writing code to represent this test? Just like you said, “I implemented the feature. I tried it out, it worked.” [laugh]. “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, “Why would I invest the time—which I don’t have—to write some tests?” The reason for that it’s just as you said: this is for regression. 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 [laugh] 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 tests of yesterday still work today because whenever you make the change, you’re just going to 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.

Corey: 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—

Angie: “It’s me.” [laugh].

Corey: —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-pasted 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? What—what—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 it, 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?

Angie: Yeah. So, a Java Champion is essentially an influencer in the Java ecosystem. You 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, a 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 to show how to do that, as well as talks and all of this stuff. So apparently, I had enough [laugh] 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 happens to be the first black woman to become a Java Champion. So, the news made a big deal about that. [laugh].

Corey: 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 IDs, 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 fixed 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.

Angie: Yeah. That’s been a gift and a curse of the language. 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, it’s 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, mmm, every three years or so.

And now they’ve committed to releases every six months. So, [laugh] most people are on Java 8 still, but we’re actually at, like, Java 16, now. 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.

Corey: 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 and whichever one you pick, there’s a whole cacophony of folks telling you you’ve done it wrong?

Angie: 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. You use Java scripts. I don’t know how this ca—I—well, I do know how it came to be.

Like, back in the day, when we first started doing test automation, JavaScript was a joke, right? People would laugh at you if you said that you were going to use JavaScript. It’s, you know, “I’m going to learn JavaScript and try to 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 [unintelligible 00:16:32] language on the client-side, back then. You had your PHP on the back end, you just did some HTML and some CSS on the front end. 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 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 asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.

Corey: If I were looking to get a job in enterprise these days, it feels like Java is the direction to go in, with the counterpoint that, let’s say that I go 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 engineering 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 leaves me with 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?

Angie: Yeah. So, I first started with C++, and then I learned Java. Well, 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, 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 divided it by language. And Java was at, like, 65,000 jobs open, Python was a close second was 62,000, and JavaScript was third place with 39,000.

So, quite a big difference. But if you looked at tech Twitter, you’d think, like, JavaScript is all there is. 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; it’s becoming more and more prevalent. If you’re going to do any sort of web app, [laugh] you definitely want to 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.

Corey: 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. Few years ago, I was a volunteer instructor for Year Up before people really 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 a 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.

Angie: [laugh].

Corey: 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 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 the 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, 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?

Angie: Yeah. So, I had the privilege of being an adjunct professor at a college, and I taught Java programming to freshmen. 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 the curriculum, that’s not really that much of a slight on them. Like, it’s just so much you have to cover.

So I, me, the testing guru, I still couldn’t find space to devote 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, 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’d do some input that they weren’t expecting and all of a sudden is broken. And they started expecting me to do this, you know? “She’s going to come and she’s going to break my stuff.” 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 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 it like a code review, 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.” So, that was my way of teaching them that quality matters in how to think about beyond the requirement.

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’ve got and realize that this is part of it as well.

Corey: 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 for 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.

Angie: 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. None of that is seen so you have to be very explicit in your messages, and your intent, and behavior with the end-user.

Corey: 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 that prolific, for lack of a better term?

Angie: 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 the number one producer of patents [laugh] of 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—[laugh]—

Corey: Oh, it’s the ‘don’t offer if you’re not serious,’ model.

Angie: Yeah. [laugh]. 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 twenty-five-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. [laugh]. So, it just so happens that 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 learn about new technologies. If something new was coming out, I would jump on that to 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 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. “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. And you’re, like, stuck.

Corey: Every single time.

Angie: Every time. So, it got—[laugh]—

Corey: Toll booths are the same way.

Angie: —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 I, 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. On your cart, you have these smart carts that know what’s inside of them, polling the customers’ spending or their behavior; 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 an overall processing time. And that way, if you display that over each queue, which one would be the fastest to get into. So, things like that is what I started doing and patenting.

Corey: Well, my favorite part of that story is that it is clearly a deeply technical insight into this, but you’ve 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 were talking about, now.

Angie: 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 A/V 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. Thank you so much for that.

Corey: 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 and 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?

Angie: Yeah. So, I’ve actually started an entire university devoted to testing, and it’s called Test Automation Universityand I got my employer, Applitools, to sponsor this, so all of the courses are free.

And they are taught by myself as well as other leading experts in the test automation space. So, you know that it’s trusted; I vet all of the instructors, I’m very [laugh] 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.

Corey: You also go further than that; you don’t just break it down by language, you break it down by use case. If I—

Angie: Yeah.

Corey: —look at Python, for example, you’ve got a Web UI path, you’ve got an—

Angie: Exactly.

Corey: API path, you’ve got a mobile path. It aligns not just with the language but with the use case, in many respects.

Angie: Mm-hm.

Corey: I’m really glad I asked that question, and we will, of course, include a link to that in the [show notes 00:31:10]. 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?

Angie: Mm-hm. 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.

Corey: 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.

Angie: Yeah, thank you so much for having me. This was fun.

Corey: Angie Jones, Java Champion and senior director at Applitools. 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.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Announcer: This has been a HumblePod production. Stay humble.