Pressure From My Director Makes QA The WORST

Transcript is auto-generated and may contain errors.

Hey folks, we're going to the experienced dev subreddit. This one is about QA testing and engineering working together or I guess the exact opposite of that and that's why this person's writing this post on Reddit. So the situation is that they have their software development life cycle. Um seems like wa that's what happens when you have let's see how many cars one two three parked along here and you can't see anything coming from the left side of the road. Um this person software development life cycle has a flow where there is like say product working with developers. They come up with like the engineers, right? They come up with the design, they go implement it. Uh, you know, code lands in some type of staging, then hand it off to QA. Um, they do their thing and then comes back to whether it passes or fails, then it can go over to production kind of thing.

So the challenge that they're facing is that um seems like their director is catching things or seeing hearing about things in production that are bugs and then I guess like sitting down with QA kind of scaring them into like you know these things are escapes, you guys are responsible for this and then QA inevitably just starts like failing. like failing all the the stuff that's passed them even if it's according to this person meeting the design spec. So, you know, engineers are just kind of building the stuff to the spec. So, like why is QA failing it? And um figured this would be a fun one to talk about. I have a bit of a biased perspective on this, but I guess that's the nature of most things, right? I'm going to have my bias. I'm going to talk about things from my perspective.

Um, if I could do a good job, I'll try to talk about it maybe from different angles, but you're going to hear a lot of what I have to say on this. So, I think uh, fundamentally this kind of uh, flow is flawed and conceptually I think it like looks good on paper and I say that because I think there's a ton of places that do this and have done this for many, many years. Um, I think probably in some places they have this nailed down and it does work really well for them and that's super cool. Um, I have never worked anywhere where this works well ever. Uh, because it inevitably leads to exactly what this person's describing. Okay. And so I think it's because uh maybe I don't know if this is like an oversimplification of what the root cause of it is, but I think one of the issues that we have here is that we're taking something that's like a pretty normal flow for things, right?

where something might be designed and then built and then tested um and then we're splitting it across different uh people roles and like sort of accountability and um I think there's probably like I said on paper like it looks good and I think there's probably you know good rationale behind this right you have people who are QA they're like their specialty is going to be around around testing and understanding things from the user's perspective and you like the there's a whole skill set perspective uh you know formal education around this kind of thing. Um so you have experts taking care of that part and you have you know the engineers that maybe are uh more trained around like actually writing code, building the software, uh putting specs together like what someone might argue is more of like the engineering part of it.

But I think the part that is a gap for me is that like when you when you split this across, it's like you're yes, you're trying to optimize around like people's expertise, which I I think that that seems like a good move, but the problem is that like the responsibility of the things um so you spread the responsibility andor shift it. So in this case when these uh QA team members are being kind of told like hey like there's bugs in production like you're QA what the hell's going on like okay well you know that accountability is now falling all on them. So to me when this person's saying now QA is blocking all these bugs or like they're not perceiving them as bugs but the QA is I'm like this I'm not surprised at all by this right they're they're trying to take accountability

and try to be responsible and saying you know we don't want to get in for this so like anything that could remotely be close to a bug like we have to stop it right even if it's not you know something crap ashing. It's like behavior we don't think is ideal. Like we might as well call it a bug otherwise we're going to get on in a week or something when this is live in production and the director's freaking out again. So like I'm reading this Reddit post going yeah like I'm not shocked. So I think that's a big part of it. And I think the other big part um and so like I would say these two pieces together make up the majority of the issue here. The other big part is that um you're making a flow of a couple of things in the software development life cycle disjoint.

And I think some of the like the concepts uh please don't don't lose me here. Uh uh some of the concepts when we talk about like agile software development right having shorter feedback loops with things I think conceptually we get a lot of goodness out of that. And I think that uh especially in more recent years where people are like, "Oh, agile's dumb. Like that none of this stuff ever worked. It's just people consulting trying to get money from you." I'm like, "I don't I don't know." Like that might be the case for some people. That's fine. Um but I think a lot of what the uh you know, original sort of goals are with agile have a lot to do with shorter feedback loops. So regardless of whether or not you like agile as a software development sort of philosophy, I'm not here to convince you otherwise.

But one thing I do think is really valuable in general is shorter feedback loops. If there was like one thing that I could you know take from different things in software uh development life cycles in particular for agile I would say like having shorter feedback loops because it's just a mechanism that keeps you more on track. If your ve like if your throughput is really high and you're able to get a lot of stuff done, right, and you you okay, this is a bit of an assumption in my statement here, but if we make the assumption that we're not perfectly on track with the thing that has to be delivered, we're literally assuming that we're doing the right thing. Like we built a design, we think this is the right thing, we think this is what the customer is going to benefit from when we land this.

We're making an assumption, right? We don't actually know until it's built and measured. We can do a lot of things to try and make sure those assumptions are on track, and we should, but we don't know for real until it's real. And so, if you're throughput high and you can build lots of things, right? Um, if you don't have a short feedback loop, you basically do a ton of and then when you start measuring for real, is this good? Does this solve the problem? Does this give the customer the the value that we were intending? If it does, great. If it doesn't, you're screwed. Like, you just did all of this effort and uh for what? Like, it doesn't deliver on the promise. So having shorter feedback loops just means that we have an opportunity to recalibrate, right? Like imagine, this is obviously exaggerated, but imagine a world where every 5 minutes you could recalibrate and know if you were building the right thing.

That would be awesome. The shorter that feedback loop, the better. Otherwise, you'd go through your release cycle and whether that's, you know, uh I don't know, some people have daily releases, could be weekly, monthly, whatever, quarterly, you get to the end of that and go, "Oh like we just did all this work and it doesn't meet the expectations or the, you know, the goal that we had in mind." So, if you have the shorter feedback loop, way better. So when this testing flow, right, or QA flow where you hand something over after everything's been built and then you go, great, here you go. Like you are delaying that interaction. And so the reason I say these two things kind of work together is that this goes back to who who has the the responsibility or the accountability, right? The accountability for quality should not just be owned by QA.

I realize QA is quality assurance and like makes it seem like, you know, they're they're the ones that have to the only ones that have to worry about quality. The whole team the whole team has to worry about quality. Everyone every single person and every single person has a part to play. Now, what I have seen work really well, enough of me complaining about things, like what I've seen work really well is where you start to blend and overlap those interactions. Okay? So, it's less about let me go, you know, design it, let me sit down with the engineers and design it, let me sit down in my silo and code it. um let me get the other engineers to go review the code and then let me just hand it off to you QA now that it's you know I've checked all the boxes

instead of doing that because the feedback loop has basically been zero from QA at that point who by the way a lot of the time if they're acting as your user proxy along with say your product owner um then what's going to happen is that you have had zero feedback up until the point where they get it handed sorry they get it handed over to them and then they start giving you feedback there's been no interaction so instead blend it right whoever is like in QA or testing right we where I was working before Microsoft we just stopped calling it QA everyone's responsible for quality we have testers right they're a specialized role. Yes, they they play a role in QA, but so does everyone, right? Everyone plays a role in quality. So, what we would start to do is when you were looking at work that had to get picked up as a developer, you would be working with a tester in the beginning.

And that might freak people out cuz you're saying, "Well, that doesn't make sense. The testers come when we're done the stuff to hand it over." And I what I'm trying to say is I think that's ineffective. I think the more that you lean into that way, the more you're going to have these situations where people are like, "Ah, shit." Like testers or QA are sending it back, right? Send it back over the wall to us and we got to go fix it and you're going to have a lot of us versus them because you're trying to get your delivered, right? You're just trying to code your stuff up, get it sent out. And then QA is like, I can't just keep letting this stuff blast out. I got to keep sending it back because otherwise I'm going to get in So you collaborate on it. You work together.

You are a team. And I think this is another reason why I don't love the idea of dedicated testing teams that operate on an island. I think that's more of like a I don't know. I I could see you doing you know embedding testers and other roles like software engineers on a given product team and then you have the role of testers where people can like I don't know like get together and talk about testing practices cross organization. I think that kind of model works really well. Um, so anyway, when you start embedding uh these things together in a team and you start working together on things, it means that you have a feedback loop that is ideally tighter and tighter as you're working on stuff. That means that as you're starting to put the design spec together, right, you have testers that are available to talk about how the hell are you going to test this thing, right?

Because if they're going to be, you know, ultimately responsible for the quality, which like I said, I don't agree with. um if if they're going to be playing that role of, you know, looking for quality, making sure tests and stuff are uh are covered, which you should also be doing as a software engineer. If that is going to be one of their focal points, like get them involved early in the design. If you go design something that's going to have a, you know, a nightmare of a time being tested, that's just going to make things harder down the road. So, involve them early. Then you start actually coding it. Cool. You get your first bit of, I don't know, progress where you're like, "Okay, everything's on track." You let the tester know, hey, by the way, everything we've talked about so far, no technical roadblocks on this.

Things are progressing well. Great. Okay. Or you hit your first roadblock and you're like, Hey, the thing we talked about in the design that we were saying was going to make this, you know, really effective for testing or uh even not, right? just different have to build something a different way like letting the tester know cool like we're going to probably have to shift on how we test this now great shorter feedback loop they're kept up to date they can adjust their plans awesome goes up for code review right and even you could say depending on how you want to do this whatever it doesn't have to be carved in stone you could have before it goes up for code review can you demo something to them and your product owner right can you demo know something working and saying like hey like I have

something functional you know can we get a little bit of a preview and some feedback on this whether or not you're doing that before after during code review you know the point is at that uh that point in time you're getting feedback other people can adjust and calibrate cool everyone's on the same page okay and then I get to sign off on code review right testers should also be looking at the code doesn't mean they have to understand it as intimately, right? Um I worked with uh one of my really good friends when I was working with him before. Um I would I you know he he would say like you know he's not a developer like not a programmer but like he he could navigate a code base maybe not as well as some of the other software developers cuz he's not actively coding

in it but like you know what's a what's a high a super highle pass on something and especially using AI tools now like cool I see all this code touch and like where are the corresponding test files that go along with this right? I would say if you have tests that are written well then other people who are not super super technical in the code should be able to read them, understand them, right? Can you have the tester reading through your tests and double-checking with you like do we have these things covered? If it's covered by automation, should the tester be sitting there clicking through the application to go test those exact same things? Probably not, right? like it's probably not a good use of their time if the testing framework is doing what it's supposed to. So again, having them on the reviews, cool. Now you have something like a Canary or a test ring or whatever um test builds.

Great. Now they can go play with that, but it's not their first time seeing it. You've been on the same page the whole time up until that point. So, um, my like fix for this is really change your whole damn workflow because I think it's busted. Um, I, like I said at the beginning of this, I think some people can find a way to make the other way work really well where you have it all spread out like that. I've just never seen it end in a way that doesn't end up like this Reddit post where you have kind of like adversarial roles and silos. So, That's my take on it. If you've worked a different way, would love to hear from you in the comments. Um because that's a another good example of showing like there's lots of different ways to work. So if you got questions on career software engineering, leave them below in the comments.

Otherwise, go to code.com. You can submit stuff anonymously that way and I would love to hear from you and make a video. Take care.