1:5 - Quality Assurance Mindset - Developing it will GUARANTEE results!

You are listening to diverse software engineers podcast, which inspires engineers to serve clients better. break glass ceilings and enjoy lucrative work. Your hosts are Eric Lau, Chief consultant at Brittany Butler solutions and Fatima Agheli up and coming engineer. We focus on the software essential skills which engineers, managers and clients need to upgrade their software projects.

Buenas noches to all you listeners out there. Yes. I said, buenas noches. That means good night in Spanish. I'm trying to learn Spanish. I did say good night, because it is almost 11pm right now where I live. What am I doing recording a podcast? i 11pm? Because it's all for you listeners. That's how hard we work at closing 11pm on a Saturday night, we could be doing all sorts of other things. Well, not so many other things. No thanks, COVID. But we're not doing those things. Instead, we are here. We calling up podcasts. Fatima. Did you know that I have some new stuff on the web a website that Did you check it out lately?

How recently was the website updated?

Oh, that was like a day or two ago?

Oh, I haven't checked since Thursday, I believe.

Oh, that's okay. No worries. I'm just telling you and sort of a way to plug the website. That's dsepodcast.com that right now. We have added transcripts.

Definitely worth checking out

The transcripts of each episode are now available. And you can go there if you're hard of hearing, or you just want to capture wonderful things that were said and don't want to miss a single word. You got it now at the dsepodcast.com. Now, I have to say, you guys were checking out right? Absolutely. So But even now when I'm showing you the website, did you like try to break it? Like he tried to like hack it, break it do something crazy?

Don't think that I'm that experienced in technology yet to do that. Maybe someday,

you don't just feel the urge to try just to see what things could break.

You know what, that that's a good idea. Maybe I'll try that. Next time I'm on there.

Is like I made made a mistake. I think I just like opened up a challenge, like Challenge accepted. Well, now our next guest here knows a thing or two about breaking things down his share of finding bugs and showing how broken piece of software is he made a software engineer or to cry along the way. How do you know I can't about that. I'm pretty sure he didn't make anyone cry. And I think our next guest will feel pretty bad about it. So we have Ken Wong here. Welcome to the show.

Yeah, thank you for inviting me. Glad to be here. So I'm excited.

Ah, Ken and I go back a long way so long that I definitely before I have children? And definitely before I was married?

It feels like a lifetime ago.

It just does. Oh my goodness, so suddenly felt like a lifetime ago. So Ken Why don't you introduce to the audience a bit about yourself how you get started in a career and how you get to where you're now?

Yeah, so then working QA since when I graduated back in 2005 that was my graduated. Yeah, I mean, it seems like a long time ago but no, I started graduated and started looking for jobs and like most people that graduated from university my voice You know, it's an intuition was like no go look for like a development job. But wasn't that easy for me? To find a development job back then? So

can you tell me what back where when is back then? back? Well,

I guess back when I first graduated, so after graduating from school 2000 Yeah. 2004 is when I finished my last course of 2005 was when I started looking for,

like 2004, right?

Yeah, it was not for me. It was close though. the.com is like around early 2000s. And after I graduated, I think it was still a little bit hard. And there was a lot of competition I guess a lot people interested in technology. I guess for me it was tough to find a development job so but that's what the teacher at school right. So that's what I tried to apply for back then. And without doing any Co Op or any internship. I didn't have much work. It's relevant work experience and you know, to fill up my resume, so it was difficult at the beginning. Though so then I started looking for other types of jobs that sort of related to my do my studies at school. My first job was actually Electronic Arts as a QA, summer intern, sort of summer contract job, though. And that's I guess that's why I started learning how to test things and break stuff. Yeah, it's quite, quite exciting.

Now, is that where the.com bust was still very much in full swing. Like, I'm trying remember the timeline?

Oh, yeah.

Funny I was actually considering to add a glass breaking sound. Whenever you talk about, like breaking the glass ceiling, like gaming, you need to feel like I don't know. That's a great idea. Not what do you guys think shots? Do you think that's a nice little sound I should add to the podcast?

I kinda like it.

It certainly makes it a little fun. Now, QA tester, Electronic Arts? How was that?

Let's just say as a first job it was after graduation, it was an eye opener of how like the industry works. So it's going to like the gaming industry is definitely a little bit more extreme to start things off? I would say so I would say okay, so some some of the memories that I have, from from that job was like working lots, lots of overtime. So the way that the game industry usually works is that

well define lots of overtime. Give us some numbers here.

Yes. Okay. I would say it was like nine o'clock in the morning would be doing that, go into the office, and then staying till like 12am, I would say, and I'll be doing that every day for the entire summer. So it was like, you know, how normal people would be like doing 40 hours a week ish. Let's just say that I've, I've seen like, my pay stubs with like to lose ish. In a week. That's that's like a normal amount that would say,

That's average.

Yeah, that's, it's, it's how things usually work as in the, in the game industries where they, where they hire a lot of QA people to test product or games that they're gonna release in, in the during the Christmas time, right. So and the basically have to finish testing within the same amount of time. And they don't give you that much time. So you have to cram it all in. So think about, like studying for a midterm and like the very last day or so and used to stay up all all night pretty much in study. So it's how things work in the game industry, unfortunately.

That bad huh?

Yeah, actually, I was curious about the game industry, especially, and working out. Yeah, that sounds really stressful. How did you manage that stress level having to work that many hours a day? Well,

thankfully, I was in my early 20s. So that time, though, I was single, I was living at home. So all I did everyday was just wake up, go to work, and come home and sleep pretty much. That was my entire summer for that year. And I honestly don't have any memories of that summer other than just going to work every day. Yeah, it was stressful. But thankfully, it was only six months. So that I moved on. And I said to myself, I was never going back to the gaming industry ever again.

What was the experience itself? Like, what's the day to day? Like? I think there are some people have the notion that testing games must be amazing, because you get to play all these favorite games. But I heard from enough people that says it's, you're not actually playing the game, are you?

know, it's um, it feels like work. It's like, when you when you playing games, you know, you got to do your own things, you got to relax and you got to go at your own pace. But when you're testing a game, you're not actually you don't actually get to do what you what you you know, what you normally do, unfortunately, you have to follow these scripts you can follow sometimes, like you have to reproduce issues. So that means that you have to follow like the reproduction steps of the of the defect. Sorry, I'm getting a little bit more technical now. But But yeah, like, so people were like, write up these defects and they'll just follow these reproduction steps and you have to see if it's actually fixed or not. Sometimes you have to like do some ad hoc testing where you have to purposely like pull the controller you know, things that you know, people don't like the when you play with other friends if you're not supposed to do things like that, but you know, when you're testing that's what you're supposed to do. Guess what says yes to the poll. The controller is also for the network cable. I always was like, do all these sorts of things I just do mess things up. So that's that's what you're looking for.

And I don't know if this is true, but I when I think of testing the game, you imagine a 3d game where you have to walk along the walls and you just spent all day walking along walls trying to find like a picture.

That's that's how you sometimes reproduce the bugs. Actually, you you do that, but it's the stupidest things that you wouldn't imagine people would do. Yes, you're supposed to be the ones is doing

Your face like towards a wall just like hit the wall. Your head against the wall, this wall that wall? Yeah, that's definitely not playing a video game.

Exactly Though you're basically you don't you don't you don't play it as you as an as a normal person.

Looking at your LinkedIn, you have a lot of experience with quality assurance. Right. And I was wondering, what would impress you about a candidate applying for a junior QA role?

Yeah, that's a good question. Yeah, right now like QA manager, I think identity so I, and I've been hiring people doing interviews for a couple years now. So um, I would say it's hard to explain, but it's more like the mindset of of QA. It's what I'm looking for. It's like, things that people ask or people, people say during the the interview, it's what I'm looking for. So what I mean by that is that, say, for instance, like some, if I'm interviewing a candidate, and I give him a problem, what kind of questions like I'm looking for the questions that they would ask me in these questions, I purposely, you know, a little bit ambiguous, doesn't exactly tell you the whole story. The reason for that is looking out for the questions that come up, like what what are their thought process? How, how their mind works. So that's what I mean by the QA, mindset. These are things that unfortunately, you don't, they don't really teach you at school. So it's not like, you know, how, like, you know, at school, they teach you like, you know, development courses and how to program in Java or c++. So, so, obviously, from languages, but they don't really teach you like QA at school, unfortunately, but so that's why it's, it's a little bit difficult for, I would say, new QA people to, to think of, like the questions that, that they'll come up if I would give them a problem. So it and that's why though, it really depends, like, you know, the experience that they have, like, for like different the role that they're playing for, right? If they if it's like a junior level, like I'm not expecting them to, like know, all the the questions that they would ask the the things that they would worry about when when you're testing something, but that's that's the get more senior that I'm expecting, you know, more more relevant questions to come up.

So Ken I mean, our listeners are probably at this point wondering, come on throw us a bone here. You said you asked questions that talk about or delve into the QA mindset. Sure. One question, one question that you asked, or used to ask. Tell the audience what you are looking for.

Yeah, so this might be giving a little bit of a given away some questions that we asked the company. But so one of the questions that I usually asked, you know, it's like, you're given like a, like a login page, like everyone's familiar with the login page, you know, there's like a username, password, you know, and you're supposed to, you know, test that page, and how would you test that page? And, you know, like a junior people would ask, oh, I'm just gonna type in the right password and the right username and click on the submit button, and hopefully, I'll get logged in correctly. Maybe tried like the incorrect password and login, try logging in? And they'll they'll give me an error message. Oh, that's, you know, this the basic stuff that most people would would would answer. But the more technical and more experienced person would be like, Okay, so what if I were to type in these different characters, like, you know, special characters, like, try to do like SQL injection, for instance, again, in the text field, where you type in like, SQL commands, and you click on submit,

Delete * from users table?

Yeah, like job table, you know, things like that. Like, basically stuff that you know, that's unexpected. That's one thing I'm looking for some of the other things I'm looking for. It's like, oh, what if you like, use like, different browsers and the my dad, you know, what, what happens if you try it with like, Chrome or Safari? You know, what happens when you use those browsers? Does it does the submit button work? Okay. In in those browsers? What if I'm on a mobile phone? I try to, you know, try testing, logging in, through my phone. Will it work properly? Yeah, basically just other scenarios that normally people don't think of.

I see. All right. That's that's actually interesting. I was thinking of like the same thing. I was considering asking the same question. I was also wondering if there was a myth about QA that you wish would disappear. What? What myth? Could it be?

It's like the myth, the site QA is, is anyone could could do QA. It's like even a monkey could do QA.

You can like, Oh, this job is so demeaning that even a monkey could do this.

Yeah, I mean, I've I've had like, hopefully, based on my personal experience, I've had cases where, you know, the developers, they don't know, sometimes they don't, they don't take up as valuable as we should be. Yeah, I guess the examples, like sort of, like, his personal examples would be like, yeah, I've had cases where they don't listen to us. Like when we were the Tom, like, Oh, this is an issue here. And they would come to the vault, we would say, I don't think so. I don't think you know, what, what, what are you talking about? I'm like, No, I'm pretty sure this is how it's supposed to work. And why don't we look at the, you know, the specs?

What do you mean, the login crashes? That's a feature what are you talking about Ken?

Yeah, exactly. Right. Like, though, it's mostly like, features that you know, how the feature supposed to work, sometimes the developer have their own idea, have their own interpretation of things. And then QA comes in and they look at that, and they look at, you know, how how it's supposed to work on and, you know, maybe through like the whole user work, the user journey of how it's supposed to work. And they think, oh, they're supposed to look this way, which then developer things supposedly worked out. And they might not have the full picture developer might not have the full picture at that time. So it's up to the QA to tell them to persuade them that oh, this is how it's supposed to work. So I think the myth goes to going back to the original question, yeah, the myth is that sometimes, developers might get a little bit too cocky. And they think that this is the right way to do it. And they don't usually, sometimes they don't listen to to what QA is. I think that's, that's a myth that they think that QA doesn't know what they're talking about.

Developers cocky? Come on. we've ever heard that one before? Right?

Yeah, I mean, not to say that every QA is perfect to have a new QA you do make mistakes.

Yeah, I mean, so is everyone. I mean, it's not so much whether you make mistakes, in my opinion, is what you do have it? Like how honest Are you in your assessment? Right? And when you all right, you don't want to be dismissed. There you go. There's the whole, like, that's so dismissive. I have seen that too. I was a developer. I have seen it. I've seen colleagues do it. Now. I'm pretty sure I haven't done it right.

No, I mean, I was sure if I if you did, I would call you out on it.

I would be sure you would, and I will thank you for that. We will get back to you after these messages.

Accelebrate your software projects or software careers by requesting a free 30 minute consultation. For details, go to dsepodcast.com.

Welcome back, listeners. We think the last segment has some juicy details and must know stuff you want to know. I'm sure there'll be more. We're back here again with Ken

09pm is late, but we're trucking along. Fatima, I know that you have a number more questions I want. You want to ask him that take it away.

Yeah, based off the last section, you were talking about developers and you know, things that you've had to test and your opinions on them. And I was just curious about any interesting stories that you've had about anything that you've had to test, or just maybe something funny, or anything that happened that you wouldn't mind share

after, you know, weekly QA with so many years? I mean, do you come up with some you do having encountered some interesting stories over the years? I would say, I mean, there have been some interesting developers that I work with some are grid, that you know, that really receptive to feedback. And I find that some sometimes, depending on which developer you're working with, you tend to know their their tendencies or their and the behavior and he tend to change your approach sometimes, depending how you deal with certain developers, for instance, like if your developer is like, tend to be a little bit more relaxed in in the development process, that's still the order. The way that they code things. I tend to find a lot of bugs them find that I would usually spend a little bit extra time particularly testing you know, the changes and Making sure that you know, everything is fine. But you know, these are things that you sort of pick up after, after working with like, a group of developers for a long time, sometimes you know that these so and so tend to introduce a lot more defects, he would tend to spend a little bit more time looking through the code or like you're testing the stuff a bit. And sometimes, you know, some developers are really, really good at things. So maybe you might just spend a little bit of time testing and you trust them that you know that, that the code that they write is pretty pretty well, you know, you're not gonna expect many bugs. They're really good developers I've seen even tested code. Shocking, I know that you test the code before they give you the QA. Yeah, not every not every. Not still.

That is still shocking. Even now. Like, with the invention of unit driven testing and, and all test first and all that that's still like a big deal?

you would assume so you would assume that every developer these days would actually test the code before they give it to QA. But no, I've worked with developers that just write the code and I swear, they must have not even ran the code when they just told me to test it right away. And within like, the first minute, I would have found an issue what

What do you mean? It works on my machine. Everytime you heard that?

Sometimes I go WTF, like Why? It's so obvious that

you're allowed to swear. What the fuck. Okay. Nobody here is gonna be like 13 or 12 is gonna be offended. I wasn't sure. what's what's the what's the average age? You can say it. It's ok.

So yeah, anyways, yeah. So some of some of the times when I've tested something within like, the first minute, I found something issue. And I clearly know, the developer didn't test that. So yeah, it's, it's after working with like, you know, same group of people for for a few years, you tend to know who is who is more better at doing a little bit more testing before they give the QA. Some of them, they obviously, just don't care. And I don't really, you know, put it in like an unexpected vocuis to do a thorough testing, but at least you know, a little bit of spot checking would be nice before they hand it over to you. It

was shocking. Maybe, maybe it's not so shocking. But I have a radical proposition. I personally think, especially, at a company like Ping Identity. Oh, by the way, um tell everyone, what does Ping Identity do?

Oh, yeah, we're a security company we work with like a lot of Fortune 500 are basically the enterprise companies where we, we do like single sign on and we do multi factor authentication, we do anything that do with identity based security, that's what ping identity does.

So a company ping identity, where we're dealing with people secret and access to secrets. In these kind of environments, I would throw the idea for this idea that any developer hiring, I think a QA person or key manager needs to be there for the interview, like, like Hippocratic oath, like these, there's some sort of all for developers whether they need to be vetted by QA.

Ideally, yes, that would be the best. That would be the best scenario, but not not all the time. No.

I know, it never happens. I've never seen it. I've pitched it a couple of times. And it's just like, yeah,

I think that goes back to the whole misconception where, you know, QA is not as important as test development, right?

And I'm going in, I always find I honestly, I don't know what, pardon, my French is having the nice thing I'd say but as ludicrous because you know, when the bugs exist, they exist. It's not like, Oh, you don't, somebody doesn't find them, and therefore they just magically disappear, right? Is that the only two ways a bug will always show up? Right? If it's there, it will show up. It's only a matter of time. And it's by who those are the only two questions like When is it going to be discovered by who? And how bad he's going to hurt you? The only question is, who would you find this bug, your QA, or your fortune 500 customer? And it turns out that 10 million users and data and secrets was stolen because there was a defect in your security code.

Oh, yeah, no, exactly like it is better to look bad in front of QA and as bad for your customer. So the way that I look at things like QA makes the company look good. And few tend to ignore QA that will mean if something you know goes out, then it's up to you guys, to me, it's

It's your ass.

Exactly always it's a it's what makes you look bad. Right bugs escaping the the development.

Yeah. So Fatima, what do you think so far? This is definitely very different in terms of mentality than your coding assignments. Right?

Yes, speaking of speaking of things that we all wish people would start doing, and, you know, just hoping people would test their code a little bit, I was actually curious, what's one thing that you really wish people would stop doing, especially developers?

Stop doing? I mean, I was thinking what what they would start doing is more like writing more more tests that will be there. The ideal scenario, I think, maybe it's just my background on QA is like, I feel like tests. And like writing tests and automation and things like that, that's really key to every every development cycle, I think, thing not enough time or not enough effort is being spent on on that portion of, of the of the development lifecycle. And I mean, like, like, I get it, like, you know, people, companies, especially don't, deadlines, and they want to ship software as fast as possible. But the thing is that if you keep neglecting the whole QA process, like not neglecting writing, automation just ends up fighting it at some point, right? Like, you just keep piling on more and more tech debt, more and more stuff, automation, or more and more stuff that he has to do you don't maintain the quality of your code, right, then. At some point, this just grow so large that it's not maintainable anymore. And then how are you approach it right? So I think yeah, we should always keep quality in mind when when you're trying to release

anything this is like you want to know the real world this is the real world of development, right? The real world of making software. The thing about it is that the stakes have never been higher. We're so dependent on software like when I first started what security right oh my god that the amount of cheese password in plain text. I mean, even at that time, I was like, Oh my god, I can't believe

No one cares about security back then.

Yeah. Oh, man, it's Yeah, so testing software, for sure is such an important and daunting challenge. To give an impression of just how daunting it is, you got to think about defending your castle, if you're the defender, you have to defend against every single angle, right everything like from the top of the structure to the bottom to the underground believe the castle itself, the mold, the bridge, like everything, you read the attacker, you just need one thing, one crack one weakness, that's it.

That's a good point that you brought up like you know, if you're like in the news, but all these like hacks and vulnerabilities that came out recently, like all these various software and it costs companies billions of dollars, if something were to go wrong, not not to say they didn't have a good quality process, but it just goes to show that that's how important that is to make sure that you've refined like all these critical defects and making sure that we test software properly

Now besides yourself can now obviously in your mind, you're the best QA there ever was. That now you're just being humbled. And that's that's a great tree beside yourself. Who would you say is the best QA that that you've worked with? And you don't have to need someone your company because I don't I know you don't want to play favorites here and get so who's the best that you ever worked with? What makes them great give a story about that story that that what this person did that make you go wow,

I'm not sure if this is the best but you say like, during during all these years that I've worked in QA like I definitely pick up on someone that's extraordinary. Like I usually like look at how people work and the things that they do to make that make them stand out right and some of the people that I've worked with have been like that I thought was extraordinary. It's like you know things that they did the attention to detail that they pay attention to is really on a different scale you know how like a like a normal person be Oh, we found this defect like okay then then they log it they enter into the defect tracker Okay, and then they move on for some people they actually keep tracking going down that rabbit hole I would say where they keep finding out Oh, this is what what causes and they will keep trying all these different combinations and basically just keep going at it until they find a root causing. These are the kinds of people that pay attention to you like, how their mind works and how how your thought process works and try to learn as much as possible.

Do you remember Carina? Yeah, of course. You got to tell a story about Carina because I there was one time that she she did some That test is somewhere that I don't even do you remember the story? Do you remember the story? Probably too bad because I don't remember details, but just remember the fact that she was able to have a step. So we produced this bug that no one else saw, like no one even considered it. But it was such a serious issue when it was discovered, like, Oh my God, we have to like, we have to stop that product release and fix it. And then we'll just like, a, is it the robot was like, What in the world? Would you even consider like, I wouldn't even never even considered it at that time was like, like how I wasn't you got a little upset? I was like, Oh, come on, I don't really get upset that often.

I think that's that's a trademark of a good QA person is the amount of detail that they go into, like, how they find these defects. If it's some obscure way of doing things. I think that that's something that you know, most people don't think of. And that's what makes a good QA person coming up with these interesting ways of breaking things. Right? Yeah.

So shout out to all the theories out there like Carina from Vivonet, from Vivonet days, you know who you are, if you're listening, I'm giving you a shout out right now. You are awesome.

I have a funny story about Carina, actually.

Do tell.

So this is like, back when I first started at Ping, she applied to Ping when I this is like during my second or third year, I think. So she applied to it. And I was actually in a panel of when I was interviewing her. They remembered most of that was that she came up with like the source code of selenium project that she wrote on his spare time. And she actually printed out all these every single piece of code that she wrote for that project. And she actually handed out to all the panel interviewers. And to look at it, I was kind of amazed. Because it's the first time I've ever seen anyone actually brought the panel interview, like stacks of code, they print it out, and she just pass it out. Like to everyone just did look at it. I'm like, wow, this is pretty amazing. Unfortunately, at that point, I wasn't a QA manager at that point. So I didn't have like that much of the same final decision of hiring it. But I did get a thumbs up. But things didn't work out unfortunately, we never offered a position.

Let's put it this way. If I were in a position to hire QA, I am going to hire her on the spot, like I'm not even gonna ask like, I'm just like, when can you start how much money you want? That's it. That's it. That's all. That's all I care about.

Oh, yeah, sure.

Maybe you talk about selenium, which I think I want to get into a little bit about tools for testing in sort of the technologies that behind that. And we will do that after these messages.

Accelebrate your software projects or software careers, by requesting a free 30 minute consultation. For details, go to dsepodcast.com.

listeners, welcome back. And if you're with us at this point of the podcast, you're amazing. And you're gonna get rewarded. We're gonna continue on with our interview with Ken. And during the break, there was a really interesting banter between now Fatima and en and I said, You guys got to ring this on air. our li teners want to know, take it aw y.

Yeah, I'm actually I was, I was mentioning Co Op, and at my university Co Op is required. And I haven't taken it yet, just because it's so intimidating. I was actually curious about your experiences, or if you have any opinions on early Co Op students and how we should approach that.

Yeah, that's a good question. Actually. Yeah, I've been hiring and interviewing co ops for a couple years now, actually, two, three years now. And definitely, you know, it's a challenging one thing is to get through for Co Op to find a position. I mean, I was in that situation going, when I was going to university as well, you know, having having applied to a whole bunch of companies and not hearing much or like not not getting the jobs, but being on the other end of things. So, as the hiring manager definitely, I would say, you know, if you have to stand out pretty much you have to stand out from from your your peers in some ways. So some of the things I noticed people that always put out in their in their resume, for Co Op, so you know, the projects that they worked in at school, the side projects that they work in their personal lives, so think those are, those are all good things to put in your resume to show that you stand out from from other people. Some of the other things that I recommend is, you know, learning tools like frameworks that you normally wouldn't work with at school. That's something that I would recommend. For me, like as a QA manager, I would try to hire a lookout for things that that's more testing oriented. So for instance, like, if someone would say that all they have to read unit testing projects and it'll be Oh, that's something that, that it's different that stands out to me, my son would like write some kind of like a test plans or do some kind of automation with their project with a with a with a school work or their personal projects. That's something that really stands out to me because you know, not not many people that I know, especially people is going to university would actually bother writing test code. Because mainly they don't, they don't really teach that at school, right? It's like, Oh, this teach you to do finish programming this, this assignment. And this handed and that's it, right? Things that you don't, things that you they don't teach you is the things that actually look up like that, that stands out to me. So you know, writing code writing test plans. That's how if you want to get a job in QA, that's things that you have to you have to focus on. Right.

So, so now you know why I emphasize writing unit tests. Remember when we did that some of those exercises like those coding that actually showed us our code to test code? Definitely, yeah, not now he saw see that the importance of it right. Not only do you get more confidence in your code easier to manually test. I always find it ironic that developers love to code. But yeah, the testing part is itself a process that can be automated, and yet they allow them to be like, Oh, I don't want to do that. Like Really? You don't want, right? You're like, I'm asking you to write more code. What do you mean, you don't want to write code? I thought you love to code? Isn't that your profession?

I have this feeling that that a lot of developers the reason why they they wanted to develop prices, they they like to develop things, but they don't, they don't like to actually make sure that actually runs perfectly. There's this reason why I think developers they go into the development field rather than the QA field, because they don't want to focus on testing part of it. They just want to write the cover, come up with the with the, with the algorithms, and then just give it give it someone else that tested that let someone else worried that if it's accurate or not, right?

You notice, when someone's writing code in Hollywood movie, you notice that Okay, here's the things you notice, right? First thing is, they always type they are always a keyboard, right? They never use the mouse

It's really glamorous.

They never ever touch the mouse 20 minute break, or if a gun to their head, and they will use the mouse. Never he's never seen it unless you unless you're like, super extraordinare like, like keyboards, macros person and I almost never seen someone.

I think most people imagined the developer as like the rock stars that that's there as like the cowboy you know, where they solve the world's greatest problems and Exactly.

About the representation you think developers are under represented?

Personally, I've never seen a movie that has QA in it has to glamorize the QA position, the third the field. I mean, that's that's my experience with things. I've never seen that movie. And if there is, please let me know, because I'm curious to watch it.

Yeah. Well, maybe more follow up questions Fatima? you want to ask them? chatting a little more?

Yeah, I was. Yeah, you were mentioning how like in school, they don't teach it very often here. And I thought that was just, I think that is crazy. Like, we should definitely be learning more about that even in school. Because I think even if you're just planning to be a developer, it could even enhance your development skills. I was actually curious about another thing. Speaking of interviewing, but is there any, like negative things that someone might do in an interview that might make you like, be discouraged from hiring them? or change your mind on hiring them?

Oh, yeah, no, I mean,

Don't show up late.

Besides what basic things like I could, I could talk a little bit about this. So. So some of the things that I remember most fondly on the interviews that I the candidates that I reject, it's the things that they that they talk about that, that that I know that they're faking it, or they things like that, it's easy to talk about things like the technologies that you know, that you've used, but it's a lot harder than it is to actually show it or to actually do it. So I would say, stick to the topics that you're really good at, or really familiar with. And if someone asks you a question, know, straight up, say, you know, you're not sure about it, or you've never worked on this before, rather than just biessing your way or like, talking about things that you don't know about. And that's that's when we usually catch people, when they talk about things and they're not sure about it makes you look bad when you talk about things that you're not too familiar with.

That definitely makes a lot of sense. I'll keep that in mind.

So I want to change the conversation a bit, because you mentioned number of words that I'm not sure a lot of our audience knows or is aware of. So you mentioned things like Selenium and AI Know what it is. But I wonder, have you explained to the audience what Selenium is, and want to go on record saying that QA is not just about manually testing things, right. There's a lot, a lot of stuff about code. So talk a little more about that definitely.

Part of QA is definitely involves manual testing. But that's not the entirety of QA, I would say, a lot of it involves automation side of things. So what I mean by that is that we have these tools for different frameworks that we use to automate the whole testing process. So for instance, like, you know, if you have a web page that you have to test, you could always get someone to click through all the buttons and go through all the pages, or you could write a program, piece of code or a piece of script that will run through the same workflows, except you'll do it a lot faster, you can do it repeatedly. They don't take breaks. On the left side, like just like, like a person where you know, they have to take breaks every few hours. Now you can run these these programs continuously if you wanted to set them like run run a certain time. So these so one of the tools that we use is called selenium, which is it's a framework that, that you will inspect, like you can use it to inspect the elements, and you can check on things on the element on a web page, then you can use it to perform actions or you like mouse clicks.

So basically, like, allows you to program 10, humans are using it, right? Yeah, 10s of 1000s of humans are using

it exactly. You can pretty much simulate anything using these tool, automate program, webpages where there's also the frame frameworks and tools, they can automate. They can automate, like install stuff, software as well. But you know, most of my experience is based on with web based products.

I was wondering what that word meant as well. So I'm very glad that you explained all that it's very interesting,

especially a bunch of other tools to those out, not just Selenium. But But I would say if you're interested in going to the QA field, definitely learn one of these frameworks. Some examples having minds like Cypress, it's another tool that we use for automating web pages. Selenium is the other one, API driven tools that we use to for automating API's, such as rest, rest assured.

So about how much time do you would you spend on average, like, do you manually inspect code versus using these automated versions,

my philosophy has always been that test something for the first time is always done through manual testing. So for instance, if your developer were to fix a bug or to create a new feature, the manual testing should always be done at the first stages where you make sure that everything works correctly. If there's any changes, you let developers know about it. The reason for that is that automation is really expensive. It did manually test, something would take probably like, I don't know, a few hours, but to automate, something would probably take maybe even 10 times that amount, the same workflow to automate it, possibly, depending on how complex the features. So you really don't want to automate things unless everything is more or less locked down. So what that means is that near the end of the release cycle, you're ready to ship something, that's would be the best time to automate things. So you would want to the other reason why for that, as I said, you can do regression testing. So what that means is that you want to run the same tests down the road, when you when you make some changes to some other feature that's close to the original feature, to make sure that you don't break it, you run these automated tests, basically, yeah, you would want to automate things near the end of things. You don't want to automate things that's constantly changing

Definitely agree. If and when you really got to consider return on investment. You don't want to test something that's in flux or a business to saying oh, I don't know how it was gonna be like, when middle changing it. Yeah, you want to stick with things that they you know, they're not going to change the law, again, the fundamental stuff, the the core that they're going to build and says, All this has to work on, we're screwed, and we haven't touched it. And it's, it needs to do the same thing, and 500 times a day. Those are the ones

and especially if you know that something is going to get rewritten down the road, for instance, like say, if you were to release like version 1.0 of a software, and you know that the UI is not that great, the developers would just put something together just to ship it. At that point, you probably wouldn't want to do much UI automation, you would probably focus on maybe the API automation. Because you know, the least API, if they were to change, it would be pretty straightforward. You can just like, go in, tweak a little bit of the parameters, tweak the endpoints are somebody that you can pretty much run everything, the automation would just run by itself that point, UI automation. On the other hand, if you change the UI completely, the whole the whole script, toast that you don't know, he might not be able to reuse anything. So you spent all these hours creating a script. And he might potentially toss out the toss it all away if it's if it's if the UI is completely rerun. Right?

Yeah, I want to go back to the co op topic a little bit. I remember before the interview, this days before the interview today, I mentioned about Co Op, can you say something that absolutely fascinated me? And you said that hiring co ops can be a challenge because a lot of these corpses, they want development jobs. So they would go to paying go to you go to interview? And then they said, Oh, yeah, thank you for your time, but oh, this development thing came up, I wan to go there. Instead, I wil share my thought, that is shame. I remember my first jo like development job, but it' really like either of a bit. Bu I have been a scenario wher I've scoped students brough brought on as a manager. And know the work they do is no going to amount to anything lik I know for a fact that thos students were there. So sort o built something that we may pic apart, maybe 10% of it. If that That's a shame, because I ca tell you that when it comes t QA co Ops, the QA calls are muc more likely work on things tha matter, important to th company, because otherwise, wh would you even have QA

right? Yeah, exactly. Right. No, I've definitely had a few co ops that I interviewed in the past where we made them an offer and later on, because they were also applying to other companies that they turn turned the offer down, because they found a another position that's more aligned to what they were interested in. But one of the things that I want to stress is that in school, of course, they always teach you, you know, development is the only way to get into technology jobs. But that's not true. Like lots of jobs out there. There's a lot of jobs out there that that's not development related, but they don't they don't focus on that in university, they think that Oh, development is the only way to do get a technology we're going to take in the tech field right there. Because, you know, they get all the other reputation where you know, such a glamorous job. And I think, no, it's it's like lots of other jobs out there that doesn't even involve code. It's in technology related as well. Right.

And actually, that's part of reason, the motivation for starting diverse software engineers podcast, because it's diverse, because in the sense that a lot of the programming start from software engineering, but there's so many professions and means that are not software engineering, but they need people with some background in that I can't emphasize that enough, especially when definitely, there's certainly a good amount of people who go into software engineering, and find out that they're just they don't like it that much, or they just average. But that's that's not mean that your life is over. Like they never is. It's there's the software development feel. It's huge. And there's so many support and other types of jobs. And some pay even better than developers actually, our last guest was Hussein and he certainly makes good good dough for your MBA and as a software solution architect as a VP of attack. So that so I want to emphasize our listeners. And second, since your we listeners are listening, so you are listening to solicited advice. And so this one solicited advice I will give about up a court will you apply? If you get a QA job, don't turn it down. Do I tell you why do not turn it down? Do not go to a development base, I can say with? Absolutely without any reservation, the QA that you do is more much more likely matter than most development Co Op jobs. I'm pretty sure that I've seen enough on the other side. Number two, being good a QA will absolutely 100% make you a better developer, I will GUARANTEE I will GUARANTEE . like like like Charles Barkley, you say I guarantee is like a scenario. I as a development manager, I would have been very impressed if developer took the time to get into QA. Because what does that tell me? That tells me this developer is not going to give me slop the whole one's gonna just not run on the machine and pass and that the developer understands that the actual quality of a product is not QA his job. Let me say it again. The quality of product is not keyways job order was their responsibility. Quality is everybody's

eye I agree, I think it's definitely the role of everyone in a company to be responsible for quality, not just QA. I mean, sometimes QA gets gets the gets the blame of you know if the quality slips, but it's definitely responsible for the for everyone in a company. You can't just pass it the buck to QA say, Oh, they missed the bug. It's their fault, right? No, it's everyone's fault, in my opinion, here, but

the bugs get introduced somehow. who introduced bugs? Right?

Well, I mean, it that's why it's up. It's up to QA to to make developers look good. I think we find a bug so that they will release good software at the end. That's, that's what that's what matters, right? It's like good software. That's all that's all we're trying to achieve is to deliver good, good, high quality software,

Making great software, software that delights, building fulfilling careers out of building great software, is what this podcast is all about. So I want to thank you so much, Ken is almost midnight here. And you're such a trooper, I cannot thank you enough. We've been friends a long time, I know you're probably doing this because of our friendship is always much appreciated, or you take your time for team with you as well want to say that this is hard work. And take this afternoon, I spent almost three hours doing post processing of the last video. So this one's gonna take a good chunk there. I'll probably get better at it. But it will still be work. And I have to go through the QA process to ensure that the podcast is up to the standards that is very important to us. Yeah. It's a pleasure, Eric. Thank you for Fatima.

Yeah, thank you for joining us. I really learned a lot today. And I think everyone else did as well.

Yeah. So next time, there'll be some new exciting things. And we'll certainly delve more into the diverse careers that are available, and also the diverse people that work in them. And I just realized this that so far, we have not had a single white man on the show. Is that crazy? Like we have not had a single white male yet on this show you that it's got to be diverse. Oh man, I've got to find a single white guy in in development. Gee, what can I find one of those? I'm sure they're around. Good luck with that. Anyway, thank you all and stay safe out there.

congratulating yourself for listening by engaging with us. You are already well ahead of the pack. Please subscribe, share with others and post about on social media. For feedback and suggestions for future episodes, please go to the podcast website DSEpodcast.com.