[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host Saron, and today we’re talking about testing code with Angie Jones, Senior Developer Advocate at Applitools and Former Senior Software Engineer in Test at Twitter.

[00:00:22] AJ: So I needed to be able to, in any given day, write in at least three or four programming languages and work with three or four various automation frameworks.

[00:00:36] SY: Angie talks about how she got into testing, some of the testing and problems she had to solve while working at Twitter and why all developers should understand the basics of testing after this.

[00:00:54] Career Karma helps code newbies with free career coaching to help them learn to code and find a high-paying job in tech in less than a year. Download the Career Karma app to start your 21-day challenge and be one of the over 60,000 people who they’ve helped get started. Visit careerkarma.com/codenewbie.

[00:01:15] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not in your backend. It also lets you use the most popular open source languages to build web applications.

[00:01:32] Learn how to code online with Educative’s text-based courses with in-browser embedded coding environments. With their newly launched Educative’s subscriptions, users can now get unlimited access to every course offered with a single fee. Get 10% off site-wide by going to educative.io/codenewbie.

[00:01:53] DigitalOcean offers the simplest, most developer friendly cloud platform. It’s optimized to make managing and scaling apps easy with an intuitive API, multiple storage options, integrated firewalls, load balancers, and more. Get started on DigitalOcean for free with the free $100 credit at DO.co/codenewbie.

[00:02:20] SY: Thanks so much for being here.

[00:02:21] AJ: Yeah. Thanks so much for having me.

[00:02:23] SY: So let’s start with getting to know you a little bit. Tell us about your journey into coding.

[00:02:29] AJ: I didn’t play with code as a child like many of the people who I work with. This just wasn’t on my radar at all, like I didn’t know that coding or a software engineer or a developer or any of those were actually a thing. I went to college not knowing what I wanted to do with my life. I decided to major in business because I felt that was broad enough to be applicable to whatever it is I do decide I want to do, but my father was an accountant at the time and dad suggested that I take a computer class because he recognized that this was becoming an emerging space, right? And so he recommended that I just take a class because I need to know how to use the thing, right?

[00:03:18] SY: True. True. Yeah.

[00:03:19] AJ: Pretty much any job I get, he knew that you’re going to need to know how to use a computer, so just take a computer course. Silly me not knowing anything about computers, I enrolled in a C++ course.

[00:03:33] SY: Wow.

[00:03:33] AJ: Yeah. Saron, I actually loved it. I loved it right away.

[00:03:38] SY: Oh, great! Wow!

[00:03:40] AJ: And this was totally new to me. It was nothing that I experienced before. So this was really exciting. And I was taking it and still unaware, like, “Oh, people actually do this for a living.” So I was just taking the course and enjoying it, couldn’t wait to run out of the class when I would get assignments because I wanted to go to the computer lab and start on my program, like I was really, really enjoying this. And the professor asked me why was I not a computer science major. And I responded like, “Oh, I don’t know what computer scientists do.”

[00:04:15] SY: That’s fair.

[00:04:16] AJ: Yeah. Yeah. He said, “This, they do this.” And I really liked this. So he convinced me to change my major and I did. So that’s how I got into coding.

[00:04:26] SY: So it’s interesting because I’ve heard quite the opposite story of people who thought they wanted to get into computer science, took that first course and then it completely kicked their butts, right? And they said, “Oh my goodness! What is coding? And I thought I could do this and it’s so intimidating.” Was there any point of it, any part of it that was intimidating or were you just good to go?”

[00:04:45] AJ: It wasn’t quite intimidating, but it was definitely challenging, and I grew up playing board games and stuff with my family. So I love a good challenge. I love putting puzzles together and things like this. Coding felt very much like that, right? So I was given a problem and I needed to be able to craft a solution to that and that’s what coding felt like to me.

[00:05:12] SY: So when you were studying computer science, I love that question, “What do computer scientists do?” Because I don’t even think I’ve asked myself that question before. Did you end up having a career path in mind? Did you know what you wanted to do with that degree?

[00:05:25] AJ: I did not at all. I really didn’t have a clear vision of it, but in switching my major, I had a really good advisor who realized like, “Yeah, this poor girl doesn’t know anything.” The advisor recommended that I do some internships while in college.

[00:05:42] SY: Okay.

[00:05:42] AJ: So soon as I was wrapping up my freshman year, I actually went and did an internship at IBM with a distinguished engineer, and so this gave me so much insight into like, “Okay, what is it that I can actually do with this computer science degree on a day to day? What does the day to day look like?” Right? And because he was so high up, I was introduced to not just coding, but lots of other things as well, like brainstorming sessions and architecture meetings and invention sessions and things like this. So that was a really nice taste and gave me some insight to go back to school with like, “Okay, I get that what I’m going to be doing at the end of all of this. Now let’s push through and get the skills that I need.”

[00:06:29] SY: So what was your first job out of college?

[00:06:32] AJ: I went back to IBM as my first job.

[00:06:35] SY: Nice! It’s a great first job.

[00:06:37] AJ: I know. It really was. But when you hire college students, you typically offer them the role like in the springtime, right? And then they don’t start until summer after graduation. Well, IBM moves very fast. So by summer when it was time for me to actually start, that team that I got an offer with had reorg. That position was no longer there. So I was offered a position to do product development, but when I got there, they asked if I could do this test automation role. And I had no idea what testing was really. That wasn’t something that was in my curriculum in school. But I asked, “Do I get to program? Because I’m fresh out of school and I got this computer science degree.” And at that point, I actually had gotten certified in Java. So I’m coming out of college like certified.

[00:07:36] SY: Wow! Sounds blazing!

[00:07:37] AJ: You know what I mean?

[00:07:38] SY: Yeah.

[00:07:39] AJ: Certified Java Programmer. So I’m like, “Listen, I need to be able to code. Will this job allow me to code?” And they say, “Yeah. Yeah. It’s mostly coding.” So I was like, “Okay, sure.” So that’s how I got into the testing space, specifically test automation and they were absolutely right. Tons of coding and I loved it. I really loved it.

[00:08:02] SY: Tell me a little bit about testing. How did you feel about that compared to just building a product?

[00:08:08] AJ: So I’ll be honest, like when I first got into the test automation role, okay, I’m fresh out of college. I’m just happy to have a job. That’s cool. I’m learning new stuff and I’m coding and all of this is great. But back of my mind, I’m still feeling a little bit cheated, like I was offered a development position and I’m doing testing and I don’t know where I got this perception, but it’s very prevalent in tech where we look at development is like a step up from testing, right? So I was pushing to go into development. So after about two years, my wish was granted and I was offered a development position still within IBM. So I go in, I do the development job, and Saron, I hated it. I hated it. And it wasn’t that I couldn’t do it. I could absolutely do it. I did it just fine. The issue was I felt like my scope had been limited by quite a bit.

[00:09:14] SY: Interesting.

[00:09:14] AJ: When I was in the testing position, it was my job to understand the entire product and for how all of the components interact with one another to be able to envision all of these various customer use cases. And so I had a really great, big picture view of the product and how it was used versus when I went into development, it was like, “Hey, I need you to build this widget,” right? And that’s cool. But that was my total focus, this widget. And so I was missing that bigger picture view and also I wasn’t able to flex my programming skills as hard as I was in my automation role because in the automation role, I’m building frameworks from scratch. I’m utilizing multiple libraries and combining them to make something new and special. All the levels of abstraction I need to be very careful about whether I use abstraction, where’s abstraction too much, whether I use inheritance. And so I was really able to strengthen my programming in that automation role versus the development role. It felt just a little bit more, I guess, simple to me.

[00:10:32] SY: Interesting.

[00:10:33] AJ: Yeah. There wasn’t much collaboration either. Everyone is kind of focused on their features and this was before the days of like stand up and all of this stuff. So we didn’t even have open floor plans or like everyone had their own office. So you would be in your office with your door closed and just building your little widget and going home.

[00:10:56] SY: That sounds sad.

[00:10:57] AJ: Yeah. So I got out of that as soon as I could. So I did that for about two years as well and I moved back into automation. Now I will say that was more of like an entry-level development role, right? I’ve done side projects since then where I’m doing full stack development and then I was able to like grasp the bigger architectural pieces and stuff that come with building products.

[00:11:28] SY: So you mentioned that you didn’t learn testing in school. And I went to a bootcamp. I don’t remember really learning too much testing in school as well. And so I’m wondering, how did you learn how to do testing?

[00:11:40] AJ: Yeah. That was the great thing as well about doing the automation because then I was team members with the testers, right? So there were about three other testers on my team who were much more experienced than I was and so I learned from them. They taught me how to think about a feature and come up with various use cases and different heuristics that you can use to figure out like how do you test something.

[00:12:10] SY: And so what was that learning curve like? Was it mostly pairing? Was it watching videos, reading books?

[00:12:15] AJ: It was mostly just observing them. I wouldn’t even say we did a lot of pairing, but just observing what it is that they are doing. Code reviews, I am a big advocate of code reviews. So looking at other people’s code reviews and how they went about writing tests was very beneficial to me as well. So you start seeing like, “Oh wow, look at these different assertions that they added. I wouldn’t have thought to add an assertion for that.” But yeah, they’re totally right. Yeah. You look at it from a human perspective and it’s really different when you start writing the code because from a human perspective, there’s a lot of things that we’re not consciously thinking about. They were actually validating. So if you were to look at an app, for example, let’s say a web app, and you wanted to make sure that this item that you added to the shopping cart was actually there. You think that all you’re doing is looking to see if that item is there. And so that might be the assertion that you would write in your automated test. But there’s so much more that your brain is processing when you look at this as a human being, like, “Is the subtotal right? Is the quantity right? Is the tax right? Is the final total right? Is the thumbnail of the product okay? Are there not any other products that were accidentally added to the cart? Is the shopping cart number, the indicator of the quantity is that correct? Is this page flipped upside down?” Like all of these things, “Is there a pink elephant that ran across the screen?” All of these are things that subconsciously we are validating. And so when you think about writing this from a code perspective, you have to be very, very intentional and think about what are all the things that are not conscious to me, but I’m still verifying and made sure that you include those assertions as well. So those were some of the things that I learned from my team members.

[00:14:27] SY: Over nine million apps have been created and run on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Also, you’re not walking through the service. So why not start building your apps today with Heroku?

[00:14:52] Career Karma is a free service started by bootcamp grads for bootcamp grads. Coaches, our current coding bootcamp students, who mentor people to help prepare and get accepted to bootcamps in just three weeks. We spoke to Kesha Lake who used Career Karma and is now an engineer at Stitch Fix.

[00:15:10] KL: I was really looking for a way to jumpstart my career, but not just getting me ready for the career itself, but to get me ready for bootcamp. I figured if I can do the 21-day challenge, then I can do the bootcamp.

[00:15:23] SY: So what was the challenge? What was it like?

[00:15:25] KL: The instructions were to speak to one person on your level and one person above your level every day and then post some sort of proof about it as a screenshot or a picture.

[00:15:35] SY: Did you know anything about coding before this?

[00:15:38] KL: I knew absolutely nothing about coding. So the 21-day challenge really set me up perfectly. I made friends, I started networking with people who would eventually make recommendations for me to get the job that I landed, but they also offered a lot of resources and support. You know, initially I was coding on my phone because I didn’t have a working laptop. Career Karma put me together with another one of their members who donated the first laptop and then I do get to upgrade to a Macbook so I’ve got another laptop from the Career Karma community.

[00:16:06] SY: So what kind of work do you do at Stitch Fix?

[00:16:08] KL: So I work on automation projects that help plan of ease the burden of our warehouse workers. So I kind of do a lot of telling machines what to do, which is exciting. It’s mostly back end work.

[00:16:17] SY: That’s fancy.

[00:16:18] KL: Yeah, it is. It’s kind of sexy and I’m really excited about it. I really leaned more towards back end development as opposed to front end during bootcamp. So to find a job that would let me focus on that is kind of a dream come true.

[00:16:30] SY: Visit careerkarma.com/codenewbie to get started. So formerly you were the Senior Software Engineer in Test at Twitter and I’m wondering what does testing and automation look like at Twitter? Because as a consumer, Twitter feels fairly straightforward, right? Like I have a little field, I put in some words, I hit tweet, it shows up on a timeline, right? It seems like a pretty straight forward app. So what kinds of things are you testing at Twitter?

[00:17:01] AJ: Yeah. Yeah. When I first got there, I thought, “How hard could this job be?” Right?

[00:17:05] SY: Yeah.

[00:17:05] AJ: And at that time it’s 140 characters. I was like, “Oh yeah, 140 characters in a button,” right?

[00:17:10] SY: Right. Yeah.

[00:17:12] AJ: But no, there were lots and lots of things. So lots of services in the background that we needed to test. The actual web app was very stable. So we didn’t do much automation around there, a couple of key scenarios there, but a lot of my effort also went into the revenue-generating part of Twitter, which is the ads.

[00:17:32] SY: Oh right.

[00:17:33] AJ: Yeah. We all forget about that spark. There’s a whole back end kind of website that’s called ads.twitter.com. So if you go to ads.twitter.com, that’s a different website, a different sub domain, right? I needed to test all of this, and this was interesting stuff, right? So you think about testing something like an advertisement system. Okay. So there’s one part that’s creating the ad. Okay. That’s simple enough. You fill out a form. You make sure that the data persists. Make sure that you can edit the data. Then you can delete it, that sort of thing. The really interesting part comes when, “Okay, now I need to test to make sure that my ad that I specified I’m targeting people with these certain criteria that these are the people that are getting the ads and not anyone else.” For example, let’s say that I’m Budweiser and I want to make sure this ad is only shown to people that are over the age of 21.

[00:18:34] SY: Right.

[00:18:35] AJ: And so I save my ad in this way. So this is where it became really interesting. Okay, so now I need to serve this ad, but how do I do that, like in the bigger Twitter world? Like I don’t want you Saron to see my goofy test ad. You know what I mean? So I had to find ways to scope the audience down, but the audience can only be scoped so far. It has to be at least 500 people if you’re to put a list of people you want to target.

[00:19:06] SY: Okay.

[00:19:06] AJ: So I needed to create like all of these test users and I don’t want to do that by hand. So I write scripts to be able to do that. So the automation is not just of the test, but also lots of other processes and like helper things to help us get set up, right? So I create all of these users, but these users must have interests as well. So now I need to have a script that will have these users tweet all the time, like multiple times a day and I need them not to tweet about anything, but they need to tweet about whatever it is that I want this user to be interested in or something. Right? So now I have to use tools. One tool that I use that I love is called Faker. This Faker tool will allow me to specify an interest, for example. So I’m interested in beer or whatever. And with that, it’ll give me some random texts that actually make sense around beer, for example. So I would have like certain accounts that would tweet those things out so that Twitter can pick up that, “Hey, this person must be interested in beer.” Right? I would need to do that and have that running on like a bill that runs several times a day so that these users are tweeting now and then I need to figure out, “Okay, is the ad going to be shown to these people and not the other people?” For example, not people who are under 21 and not people who have no interest in beer or have expressed no interest in beer. That’s really challenging as well because the ads on Twitter are not like other ads. It’s not like some banner at the top or a little side corner. It’s embedded in the timeline.

[00:20:48] SY: Right. Right.

[00:20:48] AJ: Which is brilliant from a revenue perspective, but from a testing perspective, not so much. I actually started off like, “Okay, I have everything set up. Let me log in as one of these users and begin scrolling.” And I’m scrolling and scrolling and the ad isn’t coming up. And I’m like, “Oh yeah, I don’t know when this ad is going to come up or if it’s going to come up at all.” And if it doesn’t come up, is there necessarily a book or maybe it just didn’t come up? That’s perfectly valid as well. And so you had to get like really creative here and figure out like, “How can I just make sure, like I don’t want to spend all of this time scrolling and hoping for the best.” So this is when you start working with the development team and say, “Here are some things I need you to implement to make the app more testable. This is what I requested. Let me get an API where I can provide a user’s ID and then also provide an ID of an advertisement and then I just need you to do whatever magic that you normally do in the background and return to me a Boolean expression of true or false that this person is eligible for the ad.”

[00:21:59] SY: So you created a native mobile automation framework for their iOS app from scratch, which sounds like a huge undertaking. It sounds very complex. Tell me, first of all, what is an automation framework?

[00:22:14] AJ: Okay. So automation a framework is pretty much a code base. So if you think about your development code-based, like when you open your IDE such as VS code or something like this, you have all of these files for your project, right? So automation framework is similar to that. Usually it’s in its own project. So you open up your IDE and you have all of these folders and files in there and the automation framework is usually divided into two main sections. One is going to be the test themselves and one is going to be all of the interactions with things like the browser or the API, basically the thing under test, right? Whatever it is the target you have all of this code that’s interacting with that in some way and you want to separate that from the test itself so that you can reuse that stuff across multiple tests. So those are the two main areas of the automation framework. And in there you’ll have like some functionality to be able to drive the thing, right? Drive the scenario and set up the state and then you have the code that verifies the state. So it’s a three-part set up and we say, “Arrange, Act, and Assert.” So the arrange is where you set up all the data that you need to be able to execute the scenario and then the act is when you actually do something. So what is the thing that you want to do, you do that. And then there’s the assert. This is where you make sure that what you expected to happen actually happens. So that’s pretty much the template for setting up an automation framework and setting up a test in general. So you set it up using that format.

[00:24:10] SY: So I’ve heard some people argue that testing is something that should be a part of the developer’s workflow instead of it being a separate team. I’m wondering, what are your thoughts on that? Do you see any value in having and making it a habit for developers to test their own code or do you feel like it works better when it’s its own separate department?

[00:24:30] AJ: So developers should definitely test their own code, but there’s an extent that the developers will usually go to, right? So there’s lots of different types of tests and different layers of them as well. So the most common automated test is a unit test and a unit test is basically a very small test that will check a unit of work, whether that’d be a function or a method. It’s usually something that’s very small, and you write a test to make sure that you’re checking it. So let’s say you had a unit that sums up two numbers. This is your function. So you would write various tests, unit tests to test that function, and the idea behind the unit test is that it’s only scope to testing that specific unit. Meaning, you shouldn’t be reliant on things like the database or internet connection or third-party apps or APIs that you interact with is very scoped to just that unit, right? So this is usually the developer’s responsibility. You build a unit of code, you should also build some unit test to accompany that unit, right? And then the next level up is like a more integration type test. So now we’re talking about multiple units interacting together and this could be in the form of like an API or just some other functionality, like I click a button and it calls two or three different functions or units, right? So the integration of all of that, that’s better done in my opinion by someone who is focused and specialized on testing because they’re better at coming up with the various scenarios and how to really exercise this thing. And then the final layer up is the UI layer. So the presentation of the data. So this is also. A place that needs to be tested. You want to make sure that everything looks okay, that all of the buttons and things like that are functional. So this is where also the test team helps out. I think that the developers should definitely be aware of all of these tests and how to write them, and more importantly, how to maintain them because if they check in a new feature and the tests break, you don’t want to have to go and run to the testers and say, “Hey, can you look at what it is that I broke?” You want to be competent enough to understand the tests and how to update the test maybe because you change the behavior of the application or to understand what the test is telling you and fix your code accordingly. So I think it’s a bit much to expect developers to do all of that, especially with the timeframes that we usually give them, right? So if we say, “Hey, you have two weeks to build this feature,” it takes about a good week, maybe a week and a half to build a feature to be able to write like all of these automated tests also takes a considerable amount of time as well. And I don’t think that it’s reasonable to have the same person do that. 

[00:27:57] SY: Coming up next, Angie talks about some of the most important skills people need to do testing well, what can go wrong when you don’t have good testers on your team and her 10 commandments for navigating code reviews after this.

[00:28:19] With DigitalOcean’s cloud infrastructure, you’ll be able to build faster and scale easier from predictable pricing to flexible configurations, to world-class customer support. You’ll get access to all the infrastructure services you need to grow. Plus, DigitalOcean’s community provides over 2,000 tutorials to help you stay up to date with the latest open source software, languages and frameworks. Get started on DigitalOcean for free with a free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie.

[00:28:55] If there’s one thing that comes up over and over again in our podcast, it’s that everyone has a different way of learning. We had our producer, Levi Sharpe, try out Educative to level up his Python skills. And he really took to the service’s tech space courses with in-browser embedded coding environments. And Levi, what did you take?

[00:29:15] LS: I took learn Python from scratch, so I’ve been learning Python a little bit. So I was a little bit familiar, but I found that these courses, they’re laid out in a really intuitive way. There’s like these sections that lead seamlessly one into the other. The Python 1 goes from data types and variables to conditional statements, functions, loops, and then each section has a quiz to make sure that you’re not just blasting through and like the information is going in one ear and out the other.

[00:29:46] SY: I love the quizzes.

[00:29:48] LS: Yeah. It really called me out on my BS because I was like, “Yeah, yeah, I get it. I get it, I get it.” And then I took the quiz and they were like, “You don’t get it.” And I was like, “Ah!”

[00:29:58] SY: You got me.

[00:29:59] LS: You got me. And then throughout all of these different sort of sections, you can code within the service itself. So you don’t need like an external coding thing. I should know what that’s called. Do you know what that’s called?

[00:30:14] SY: I’m not going to tell you. I’m not going to give you an IDE.

[00:30:17] LS: Yes, that’s what it says, an IDE. Did you know I’m a producer for a coding podcast?

[00:30:23] SY: A technical podcast.

[00:30:24] LS: Yeah.

[00:30:25] SY: Two actually, two technical podcasts.

[00:30:26] LS: That’s true.

[00:30:27] SY: Get 10% off site wide by going to educative.io/codenewbie. So you are currently working at Test Automation University, which is part of Applitools. Tell me more about this university. What is it all about?

[00:30:47] AJ: Yeah. I decided to create this and not because there was a lack of educational resources out there, but because there were too many. There’s so much out there that it’s very noisy and you can’t determine or distinguish what’s good quality material versus someone who was teaching me the wrong approaches. Now automation is one of those things that fails a lot, like the process of it. People begin a test automation project and most companies fail at this because it’s a lot to consider and you can’t treat it like a side project. It has to be treated like a straight up development project and a lot of people don’t do this. Right? And there’s a lot of bad practice. I mean, all of the things like practicing good coding conventions, all of that is applicable in automation code as well. And so I wanted to start Test Automation University to be this one-stop shop where there is quality educational content for people. So it’s an online website with these online video courses. All of them are absolutely free. They’re taught by not just me, but also other experts in the automation space. So I find whoever is the expert in X topic and I ask them to contribute a course on Test Automation U for that topic and everyone has been on board. Everyone I’ve asked has been on board. I’ve vetted these people. I know that they know what they’re talking about. And so people come here now and realize like, “Wow! Okay, I have a roadmap. I have a plan. It’s laid out. What courses should I take? And I know I can trust all of the content here.” And I’m really thankful that my company athletes who sponsors Test Automation University, and that’s how we’re able to offer this for free for the public.

[00:32:51] SY: So tell me about your thoughts on education, because you’ve created a whole university, a free university to educate people on automation, but there’s also going to bootcamps. There’s teaching yourself, there’s getting a four-year CS degree, and though testing isn’t necessarily explicitly taught in all these places, what are your thoughts on education, especially if someone is interested in getting into test automation? What do you think is the best pathway to reach that destination?

[00:33:24] AJ: So education, and this is something that I’m really big on, and I don’t necessarily have a preference on how you get that education. I think different strokes for different folks and some things that work for you might not work for me and vice versa. Right? So however you get that knowledge is okay with me. For automation, this is just something that’s not taught in school, especially at the level that you need in order to succeed. Now there are some things about automation that you can pick up in school, whether that’d be bootcamp, whether that’d be a university, whether that’d be just a one-off class that you take online somewhere, and that’s like the programming skills. You have to be a strong coder to be able to do this and then design principles as well. So understanding about design, about codes, mails, all of these things are applicable to any code that you write, and it’s no different with test automation as well. So my focus with the university is to provide those types of courses. So I’ve created a Java Programming course, for example, which actually has nothing at all to do with automation, but you need this core skill before you’re going to be able to jump into any of the other courses there. So I offer that, and I’ve had not just testers, our automation folks take this course, but people who are interested in getting into development as well or people who are like, “You know what? I know JavaScript, but I’ve been kind of intimidated to learn Java. I might check out Angie’s free course.” And so people have been doing that as well.

[00:35:08] SY: So you mentioned that as an automation tester, you’ve had to at times learn multiple languages and be comfortable building these systems across different languages. I’m wondering what are some of the other important skills and things you need to know to do testing well?

[00:35:25] AJ: So to do testing well, I would say it’s a really creative job. So you really need some imagination here. And I feel like a lot of people lack that, especially when we’re in a hurry. You are thinking about, “Okay, we need to build this feature and we’re building it because this is the request that has come in.” And so a customer has specified exactly what they need and what they plan to do with the feature. And so you build it that way. You really need a tester who has the imagination to think about all of the other customers and how they might use this product, like what are some other ways to use the product, and envision that and be able to test those things out as well. So I’m going to say that’s like one of the top ones. Another one is analyzation skills. So you need to be able to analyze what’s going on with the product, right? It’s so much more than just like clicking buttons and waiting for output. You need to be able to dig through the stack and understand like if something didn’t work, why didn’t it work? It’s not enough to just say, “Oh yeah, this didn’t work.” You need to basically get down to the root cause of it. So it’s not uncommon. So pull up the app and begin debugging this thing and figuring out exactly like what’s causing the problem, and then you open that bug and say, “Okay, here’s the issue. It’s due to this function, line 34,” and be able to give the developer that feedback so that they can quickly fix it. So a lot of technical skills go into testing, a lot of creativity and imagination and also customer empathy. So being able to empathize with the customer and be an advocate for them, right? Because some things are not going to be a part of the feature, right? But as you’re using it, you say, “You know, I don’t know, the usability of this just does not feel good. It’s not obvious to me how to use this feature.” And you would provide that type of input as well, which technically this is not a bug and this isn’t what we said we were going to do, but you need someone who’s vocal and will be able to advocate on behalf of the customers.

[00:37:48] SY: So we talked a lot about the benefits of having good testers and having testing. I’m wondering what is the worst-case scenario? What happens if we don’t have a good team of testers?

[00:38:01] AJ: Usually quality suffers. And this is not impossible. Developers can be very quality minded. It just takes some effort, right? So it takes more than just studying whatever it is that you’re studying, like whatever you’re the expert in like, “Oh, I’m an expert in React.” Okay. That’s great. You can be an expert in React, but it’s going to take some reading, some studying, some listening to podcasts. Some going to testing conferences, listening to testing workshops and things like this to be able to really keep up with the crap and keep up with the skills and the techniques that are needed to be able to do it.

[00:38:40] SY: So I understand that you have 10 commandments for navigating code reviews.

[00:38:47] AJ: Yeah, I do.

[00:38:48] SY: So you have number one, not take it personally. Number two, don’t be married to your code. Number three, consider all feedback. Number four, articulate rationale for what you coded. Number five, compromise. Number six, contribute to other code reviews. Number seven, treat others how you want to be treated. Number eight, do not be intimidated by comments. Number nine, don’t repeat mistakes. And number ten, embrace nitpicks. And I think this is all so interesting because it’s very receiver centric, like it’s not so much on how to give them, it’s I think almost all of them or about how to receive them and have a more positive experience the next time.

[00:39:28] AJ: Exactly. Exactly. Code reviews is something that I’m really passionate about because it’s helped me so much in every team that I’ve worked on, not only in getting my code reviewed, but also learning from other people how they do things. You learn more about your code base as well, like what’s in here, what are the new things that are being added. So one thing that’s really difficult for new programmers is navigating the code review. So if you’re someone who you’re a junior programmer or you’re new to a team, then you kind of get a lot of comments about people saying that you’re doing this wrong and you’re doing that wrong and it can be deflating, like you feel like your team doesn’t respect or value your work and then you start developing imposter syndrome and things just go downhill from there. So the 10 commandments that I wrote are much different than what I’ve seen out there. What I’ve seen out there is how do you perform a code review and it gives tips on how to be a nice person and how to give feedback and stuff. What I didn’t see is how do you receive this feedback and how do you navigate these comments that you’re getting because the truth of the matter is everybody is not nice. Some people will be a little harsh. Some people are very blunt. They don’t even really mean harm, but they’ll say like…

[00:40:58] SY: This is how they talk.

[00:40:59] AJ: This is how they talk and they’ll say like, “Oh, this is so dumb. Why did you implement it like this?” And that will crush you because this is your baby. You pour your heart and soul. You spent the entire week coding this. You felt really proud. You checked it in and now everyone is beating up on it. So these 10 commandments tell you like, “Okay, how to go through this? How to receive the feedback? What might they be thinking? How do you respond to this feedback to get them off of your back? How do you learn from this feedback and make sure you’re not making these mistakes again?”

[00:41:34] SY: So if people who are listening are interested in getting started in automation and testing, what are some good tools or resources to get them started?

[00:41:43] AJ: There is an organization called “Ministry of Testing”. Ministry of Testing has a really great community vibe. They provide a lot of information about how to do testing well, what’s going on in the testing world. There’s blog posts. There’s courses on all the things testing. So I really love that community. They also do conferences as well around the globe. So I really liked that community. Then I also have a blog where I write about, that’s all I write about, is automation techniques and strategies and that’s AngieJones.Tech.

[00:42:27] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Angie, are you ready to fill in the blanks?

[00:42:35] AJ: Let’s do it.

[00:42:36] SY: Number one worst advice I’ve ever received is?

[00:42:40] AJ: The worst advice I’ve ever received is to just do your job and stay low. 

[00:42:45] SY: Oh, tell me about that.

[00:42:46] AJ: Yeah. The idea here is to kind of stay under the radar and above the fray in the workplace, believing that if you just do your job well, then that’s enough, but that’s not enough at all. I remember receiving a bad review early in my career because I wasn’t fully engaged with my team. Meaning, no one knew what I was working on. In meetings, I was really shy and afraid to like speak up and share my ideas in the meetings because I thought, “Oh, it’s probably stupid. Everybody here has more experience than I do.” So I know this is probably a really simple idea that they’ve already considered. So I just wouldn’t speak about it. But I’ve since learned that it’s the vocal people who get the advancements. These are the people who get more opportunities. They are the ones who are getting the promotions and the raises and are sought out for their expert opinions on things. These are the people who are considered the thought leaders and the experts, and it’s kind of in line with that old saying, “The squeaky wheel gets the grease,” right? I mean, everyone that you work with is smart. They wouldn’t be there if they weren’t smart, but there are some of those who kind of shine, and it’s the ones who are not afraid to speak up and share their ideas.

[00:44:10] SY: Number two, best advice I’ve ever received is?

[00:44:13] AJ: The best advice would be to keep it simple.

[00:44:18] SY: Tell me about that.

[00:44:19] AJ: And sometimes we feel like our code has to be clever because we want to impress our team members, but simplicity is always best. It makes it easier for everyone to understand and more importantly, for everyone to maintain. So this was something that I didn’t always think about is like the maintainability of the code, like I’m not going to be here forever. I’m going to move jobs. I’m going to move States in some cases. You might not know me come next year, but my code has to live on and someone else has to pick that up. So it’s really good if they actually understand it and can easily modify it when needed.

[00:45:03] SY: Number three, my first coding project was about?

[00:45:07] AJ: So my first big coding project that I can remember was in undergrad and we needed to code a robot to understand our voice controls and act accordingly. So we programmed it to just do like basic navigation. So how to turn left, how to turn right, how to move forward and move backward. But that was like the coolest thing to me because up until that point, I’d done very small little homework, assignments that were just straight up software. But this was an opportunity to see my software interacting with this hardware piece, this robot, and actually see the magic, like an action in the real world. That was just so exciting to me.

[00:45:52] SY: Number four, one thing I wish I knew when I first started to code is?

[00:45:56] AJ: So I wasn’t until I began teaching coding that I realized that programming is like this big toolbox full of tools and each programming concept is a tool. So things like conditional statements, that’s a tool, loops, data structure. All of these things are tools. And the toolbox is language agnostic. Once you learn what tools are available, you can pretty much solve any coding problem in any programming language that you need to, right? So given a problem, you think about which of the tools can I use and then you’d look up the syntax if you need to, and voila. So I stopped trying to memorize like all of the syntax of every single thing. And instead I focused on learning how and when certain tools can be used and this has allowed me to pick up new languages really quickly when I have to and actually be productive and produce results in using them.

[00:47:01] SY: Well, it was so wonderful getting to hang out with you. Thank you so much for joining us.

[00:47:05] AJ: Thank you for having me, Saron.

[00:47:13] SY: This episode was edited and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.