328. Do We Still Need QA In Light Of AI

With AI checking my work, do we need a QA department? Is quality assurance still a relevant job? Should people looking to get into software development consider a QA job? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:05

With AI writing so much code, do we even need a quality assurance department? If I can ask my AI to evaluate code, what's the purpose of having a QA person around? Now right up front, I'm gonna tell you that yes, QA is absolutely valuable and not replaced by AI. And as an aspiring developer, going into a QA role might be a good choice for you. But let's talk about why QA is valuable still and why AI can't just replace them in today's episode of DevQuestions. Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about quality assurance team members and why they are still valuable. And let me start off by saying that not every company can afford a dedicated QA person or team. I've been on a number of those teams. But in that case, you absolutely need someone who can fill that role. So the question becomes: what does a good QA person do? And I did say good because not every person in QA does a good job, just like not every developer does a good job. But let's talk about what a good QA person does. And I put it into four categories. The first category is ensure software quality, not necessarily make software quality. Again, QA people are not necessarily developers. They can be, and I find that's often valuable if they have some development skills. But they're ensuring software quality by doing things like testing. They're looking at regression and making sure that they prevent regression in their code. By the way, if you don't know what regression is, it means maybe you fix one problem, but you solve or you cause other problems while you do so. That's regression. Um, something that was working isn't working anymore. So they they work on testing, they work on preventing regression, they work on identifying defects. They try and pick apart your code, how it works, and find all the issues. So they ensure software quality. That's number one category. Number two is they understand the requirements, which sounds weird, right? That's that's one of their jobs. Yes, absolutely. They need to be the ones that really understand the requirements. Now, developers, we should know the requirements backwards and forwards. But the QA person needs to know from the user perspective what the requirements are. And a lot of times the requirements don't get put into a document. And yes, I know some people love to have these huge long documents that explain everything about the system. It's never enough. It's never enough, it's never right, uh, it's never complete. Understanding the requirements from the user's perspective is really important for QA. Now, this may be where there's a hybrid role with the business analyst. Business analysts and QA people are different sometimes and sometimes the same person. Um, I've I've seen pros and cons for both. But if they're in a hybrid role, this is where they also have gathered the requirements in the first place. They're the person that sits between the user and the developer, and they know the role really well. So either way, they understand the requirements. This is really important because they're the ones that are gonna test the requirements. They're the ones that are gonna validate if the requirements are being met. They're a person outside of the developer who knows what should happen and verifies it does happen. Because too often as developers, we're really close to the issue. And you know, we've got our nose right next to the code. We're we're working on making the code, we kind of lose track a bit of the overall goal sometimes. Or we get you know working on our feature and somebody else working on their feature, and we kind of mash all together and say, hey, there you go. And there's no one looking at it and says, wait, wait, wait, here's the overall requirements. We're missing some. Or these things work, but they don't work well together. Like understanding the requirements is really important. And then understanding how to evaluate if you're meeting those requirements is really important. Number three, kind of goes with number two, but number three category is they represent the user. And that means they're looking for things like is the is the application intuitive? Your application can work, it can meet all the requirements, and it might not be intuitive, which means it really should fail QA because the user has to be able to use it. I was talking to a person on YouTube today about this where they said, Hey, I think I've built the right user interface, but the user says they want something different. What do I do? Well, at the end of the day, the user is the one using your application. I built systems that that worked and that were logical and that had all the right pieces and they weren't intuitive or they didn't behave as expected. That's another part of this, is they check to make sure it behaves as expected. For example, tab order. This is one that I used to get wrong every once in a while when I was a young developer. Uh I was using uh VB6 when I was first building applications, and you would drag things out of the form. But if you drag things in the form in the wrong order, well, it would assign tab order based upon what the last tab item was that was put in the form. So I'd I'd put things in the form and then drag and rearrange them, but the tab order wouldn't rearrange with it. So maybe you know, a simple example, you might be in a uh a field that asks you for your address. So it's street address, city, state, zip. And you go from street address and you hit tab and it puts in the zip code field. And then you hit tab and it goes back to state. And you hit tab and it goes to street address too, or like it, it's all over the place. And you're like, what's going on here? That's not behaving as expected. Checking tab order is not necessarily something that developers often do. We say, yeah, they're all there. But the QA person goes, yes, but it's not behaving as expected. And then with this, they're representing the user when it comes to performance, where they go, yeah, it all works, but it takes five seconds to load a new page and they need to move. I've worked with people who have worked on a heads-down program, I call them, where they're not using their mouse. They're just putting as much information in as possible. They're just taking the data from paper and putting it in the computer, or they're filling out information as fast as possible, and they want to make sure their system doesn't hold them back. And I've built systems where they held them back, and they're like, you're killing me. Because my job is dependent on how fast I do things, and your software is making me go slower. That's a problem. QAs have to step in and say, hey, you know what? No, this is not performant. This is not doing the right thing for the user. This is not the representing the user and saying, hey, they need better. So that's category number three. Category number four is they improve the process. So the process of getting the requirements to the developers, getting the requirements turned into code, getting the code tested, and getting the code back out to the user, that whole process can be improved by QA. That means they might create automated tests. It might mean they improve uh procedures and how you do things. That might mean they train the developers on where the bugs live or what the users actually want from their application so they can just do it the next time instead of having to have it come back from QA as a fail. And they build better test cases where they say, hey, you know what? There's some things that I've seen in when the users are using these things that we hadn't accounted for. And let's let's account for those things. So QA does a lot of great work. And there's a there's a difference between working on software and working on good software, right? There's a difference between saying, hey, it works and it works well. And QA is often the group that brings out that difference. So let's ask the question here: why can't AI do this? Because it seems like that's a role for AI, right? No, because AI doesn't actually fully test its own code. You might see, you know, AI writes code and goes, oh, I've also written 150 tests. Yeah, but those tests are written by the same person who created the code in the first place. They I'll often find the tests are really bad because they have the same assumptions as the code does. And so they're not actually testing that the functionality works the way it should. They're testing the same assumptions they had that were incorrect. So that's a problem, but it doesn't even understand all the code. And so it doesn't understand the greater context because it doesn't even have enough context window to put the entire code base in. And so what it does instead is it makes assumptions. And we all know that assumptions aren't good when it comes to code. Number two, AI only understands what you tell it. And even then, not necessarily all what you tell it. So when it comes to requirements, somebody has to gather those. And the user saying, here's my requirements, isn't gonna be good enough. And the developer saying, Well, I'm gonna give it better requirements. Unless you're good at QA, you're probably not gonna give it great instructions either. You'll get better instructions, much better instructions. But there is something to understanding fully what the user actually wants, how it actually needs to work, not just what they say, and then translate that into something that can be easier to understand as a developer. That's just something that AI can't do. Also, AI does not represent the user. It doesn't understand the user, it doesn't understand where they're coming from, it doesn't empathize with how they've done the work. It hasn't actually done the job. It hasn't learned because AIs don't learn. And so, yeah, even the memory files, not good enough. So it doesn't represent the user to go, hey, this needs to be more performant because this user does it things this way. It doesn't know about that unless you told it, which again comes back to it doesn't understand anything you don't tell it. And number four, AI isn't good at performing or improving procedures. Yes, if you push it and ask it and work with it, it can give you better procedures sometimes if it actually understands the problem. But more often than not, it's basically you like frog marching it until it gets to the point where it like gives you back what you were asking for in the first place. Right. So it's not good at improving procedures. So you need QA. And as a developer, if you haven't worked with a good QA department or you don't have access to one, I would encourage you to work on building up your own skills in this area because this is going to make you a better developer. The more you understand the QA role, the better you get at it, the better you will be as a developer. And which is also why I encourage new developers who are struggling to find development roles to look at the QA roles. They aren't the same and they often don't include development. So it's not like you're just, you know, developer and waiting necessarily. They can be. But what it does do is it gives you the skills and experience you're gonna need to be a better developer when your time comes. The role of a QA developer is something that is badly needed in a lot of organizations. I see a lot of companies that are kind of skipping that because who needs quality anymore, right? We have quantity. Quantity is not the solution. Quality is a solution. That's where you get the sticking power of an application. That's where things go from they work to they work well. So if you have your QA people in your team, give them a hug. They're awesome. Um learn from them. And if you don't, learn how to be them. And even if you do, learn from them. Learn how to be a better developer because you learn from your QA people and get better at understanding what they do, why they do it, and how you can incorporate some of those same techniques into your development experience. Okay. QA is important. AI can't replace it. It is a necessary role to put out good software, not just working software. All right. Thanks for listening. As always, I am Tim Corey.