What Makes A Good Tester Within A Development Team?

Transcript is auto-generated and may contain errors.

If folks were going to the comments today, this one is about QA. And so this person was asking uh from my perspective, what things can be done from QA or like tester roles uh to be able to make the lives of software engineers easier? Uh and if I've basically like worked with people that that kind of embody this. Um, and I think this is a really great question uh for some some people in their careers depending on the companies they're at. Like this might be a a more common setup where you have like devs and QA. Um, sometimes you might have QA is an entire team separate from developers. Sometimes you'll have those roles uh within the same team and some places don't have QA or testers as a dedicated role. even though it's a sort of expectation of a development team. So you know bunch of different angles here but uh this person in particular is asking about when when that is a dedicated role.

So to start I would say um just because I was talking about like team organization I don't uh I don't love the idea of QA being separate uh from a development team. uh and for you know to be very transparent about my sort of bias I guess I don't I don't love having a dedicated QA role in maybe like a more traditional sense and my reason for that is like I think that if you have a role especially when it's like uh this might sound pedantic but when the role is titled QA for quality assurance insurance and you have a role for it. To me, uh, from my experience, it's been like that allows other people to to like seemingly want to punt that responsibility. Like they're they're not responsible for quality and surprise like everyone who's contributing to the product is responsible for quality. Um, so I don't love QA as a dedicated role.

uh testers like again maybe it's pedantic but like having a tester role um you could have a similar type of issue where it's like okay what are the testers the ones they're the only ones who really have to care focus about tests and again I don't I don't think that that's true or fair so as a dedicated role in the traditional sense I don't love this but uh I think if you are I don't know if there's like openness around like what that role is responsible for. I think you can have um some goodness come of that. So like for example um like okay let me let me put it this way. I would say in a in a traditional testing role and things have changed obviously especially there's like fewer excuses to to not be like coding I guess but in the traditional sense

my experience has been that QA and testers they don't code or they code minimally and so like there's a lot of manual testing work and I think there's a very much a time and a place for that. It's not like you're never allowed to manually test something. That's a really great way to explore functionality of something, but uh when when you rely on on your test being manual, and that's like you are you are the thing that runs the test suite as a human, I'm like, we have a problem here. That's uh that's kind of where it falls apart for And so if you're in a position like that and not pushing towards having that part become automated and being part of that solution, that's a really big gap for me. Okay, but that's just a little bit of background I guess from from my perspective on on the role and like maybe team organization.

So I do just to kind of summarize it don't love having a dedicated tester or QA role in the traditional sense but um if we were to have something like a tester role I would like that uh to be someone who is a uh basically like either test strategist focus on being able to uh understand like the gaps in how we test our test architecture uh andor someone who and contribute towards uh such frameworks uh and enhancing like basically like also contributing code in the sense that it's like if there's gaps and test coverage like how are you helping facilitate that especially with like legacy systems and things like that but embedded in the team not not as a an island. Okay. So the the main part of this question was around like you know what can QA role do to help uh make the lives of developers easier and as I talk through this part it might become more clear why like the I don't like it on an island kind of thing.

um I wanted embedded in the team like why that's sort of the case from my experience and I would say like the easiest way for me to explain what makes the lives of developers easier is kind of looking at what not to do or what I think is uh maybe a bad setup and this is a common one and it's actually not specific to QA but um the word I'm going to use is is adversarial and I want to kind of elaborate on this. So, uh I think that there are many situations in software engineering and this is probably something that exists outside of software engineering. I'm just not super familiar with life outside of software engineering. But the idea behind something being adversarial is like when your role or when you believe that your role or responsibility is to be like pitted against some other team or person.

Uh to me that's adversarial and I don't mean in like a malicious way but what I do mean is like if you were to think about QA in testing and if the way that you measure success in that role is to is just to find bugs then I would say that's a a metric that kind of encourages an adversarial behavior. Okay. So, in my opinion, the goal of testers and QA is not to find bugs, which maybe sounds kind of silly, um, because you would say, well, isn't that like what they're doing? And like, partially, yes, but that's not the goal. The goal is not to find bugs. In my opinion, if I were to to word it, it would probably be more along the lines of like the goal is to help ensure that we have high quality, which means preventing bugs from being created in the first place, right?

Finding bugs is one such thing that could be done. But at the end of the day, if you are quality assurance, you are helping ensure quality. One of the best ways to do that is to help ensure that we don't introduce bugs in the first place. When things are adversarial, when you have people that are like, "I found a bug. I found a bug. I found a bug." What will happen is that if the metric that they're trying to focus on is the number of bugs found. And I and I mean this like hopefully you can uh maybe extend what I'm saying to even other uh roles and responsibilities when there is such a a metric you like humans are like we we will game things like if that's what we're measured on okay like how do I go find as many bugs as possible? So, you know, you'll try any number of things just to be able to, you know, be able to say you found a bug.

You get into territory where it's like, I found a bug. And it's like, well, that's actually like, you know, how how it's designed. Like is that a a bug or is that just your opinion or like at some point it's not it's not contributing value like finding a bug finding a bug itself is not end to end uh contribution of value. So contributing value would be the combination of finding a bug and ensuring that it's fixed. Even more value is ensuring that bugs don't get introduced. But finding a bug and ensuring it's fixed means that you're collaborating with other people. So it's not like the addition of value is not I found a bug. Like if you're trying to ship that value, the addition of value is we eliminated faulty behavior from being shipped to a customer, right? And that requires that not only is something being identified, but something is being fixed and that's a collaboration.

So when the goal is just find like a certain number of bugs like that's your goal I think that gets gamed and it creates an adversarial relationship. Uh I think to uh you know the next part of this is like this island effect. If you have a team of QA, right? If you have a team of QA, then what ends up happening is that you have a longer period of time between when things are being built and when quality is trying to be measured. And I think there's a lot of evidence that suggests if you have a tighter feedback loop in general in software engineering that you can create better software, you have the opportunity to create better software. This is where things like agile come into play.

And I don't necessarily mean like you have to go, you know, live and breathe the agile manifesto, but the idea being that if you have the opportunity for feedback earlier, then you don't do something wasteful spending time on it just to realize there's an issue way down the road. Things are more expensive to fix or change later on. So when you have a team of QA and that is separate from the rest of the the software development team, I think that you're just sort of creating delays and issues uh in in being able to have uh you know quicker feedback. So what I've seen work really well from testers in QA is to be embedded in the team. It's to not to not separate QA and testing from the software development process itself. So for example, if you are on a small team and it's like okay we're starting a sprint or whatever like you depending on what you follow some new work is going to be started.

if this is work that needs to be designed because it's a larger feature or something like that um and you know you have to put a design document together whatever that looks like in within your team if that's a process you follow then it's not oh I'm going to have an engineer work on this in isolation like you might have someone who's responsible and owns it and is doing the majority of the writing and you know takes ownership of it but they should be involving other software engineers. And if you have QA or testers, they should be in early on that as well because if they're going to help ensure quality or help ensure that there is uh adequate testing, I I shouldn't use a word better than adequately uh that there is, you know, high confidence in the test being put together to ensure the behavior of this this functionality is met.

you would want them involved early. So, I've seen that work really well when people are brought into those conversations like basically right from the start. If you don't do design docks for for whatever reason, whether that's just not a thing on your team andor the size of the feature maybe doesn't warrant the paperwork behind a design dock, um, then I would still say like bringing in a tester or QA from the start, having a conversation with them. It'd be like the way I see this is if you had to work with, you know, someone who's created this this ticket for you to work on, right? this user story, this feature, someone's made this request, right? So, your product owner, whoever, it would make a lot of sense to me that when you go to start this work, you talk with them, right? Hey, I'm picking up this feature.

Uh, I see what's been written down. Like, I just want to double check these things before I get started. Get some clarity and move ahead. Right? I would also recommend that you talk with if you have a tester or QA role that you're talking with them from the start because again if that's your team organization and that's a role that's on your team how are you going to work with them to ensure that there is quality baked in from the start that it's not an afterthought because that again creates an adversarial type of relationship where developers like I'm all done, you know, like ship it and then QA is like now I'm going to go ensure the quality and no, like unhip it or fix it. And so instead of doing like a me versus you thing, why don't we work together on on ship like building and shipping the thing?

There's an opportunity for it. So I've seen those types of relationships in software development teams work much much better that from the start you are partnered on trying to ensure quality in the feature that's being built. There's alignment on it. Um one of the things that I think is incredibly important here is that and I I can say this as an engineering manager who's not living and breathing in the code. Whoa, a bird just flew in front of my car. Um, when you have someone who is not going to be like actively in the code, you might be able to say like as someone who programs a lot. If you put me on a code review, I can go try to ensure that there's like good coded test coverage. maybe someone who's less technical or has less time spent in code.

You might have really really really good uh you know confidence building high coverage coded tests for the feature that you're building or the bug fix that you're doing and you might feel like man this is rock solid like there is nothing else there's no no stone left unturned and that might be true but like if you're working with someone in a testing role or QA role if they don't understand what you've done right and I'm not saying that's because they're incapable or not smart or anything else. Like if for whatever reason if they don't understand the coverage that you've put in place, then it kind of like again the their role and responsibility is to ensure quality. So they kind of have to if they don't understand they should assume that there's nothing covered because they don't know they don't know what's covered.

So, um I think there's a really good opportunity to sit down with people that are testers and QA, especially if they're not super familiar with code bases to be able to walk through them, walk them through like the code changes and the test coverage and say like, "Hey, look, I have these scenarios. Here's how I ensure that." Um, even if they're not picking up on the exact details of the code, you can you can guide them through. And it's such a good opportunity for them to say cool okay like we have this this and this what about you know these angles how are we ensuring this kind of functionality um what gives us confidence in this scenario and again like having this conversation with them and being able to map out like genuinely what's covered.

There were so many times from doing this where the the test person would be able to call out like tons of different gaps and so many opportunities where I was able to give them confidence and saying like look this is exactly how this works and exactly how I have the confidence in a coded test. So, like if you were to tell me how you would maybe click through a user interface or whatever else, I'll tell you what parts are are literally exercised and they could go through their sort of mind map and list and be like, "Cool, like I literally don't need to go do this manually because it won't add value." Um, so yeah, I think one of the best ways to get testers in QA to be uh more effective is is to partner them with engineering, not to make it adversarial. Hope that helps.

Um, if you have questions on software engineering, career development, leave them below in the comments. Otherwise, go to code.com. Take care.