What does it really mean to be a Test Lead? In this episode of PLATO Panel Talks, host Mike Hrycyk sits down with experienced testing professionals Sal Bugliarisi (Accenture) and Bhavya Bhatnagar (PLATO) to draw on their real-world experience across projects and teams.
The panel discusses how Test Leads influence testing strategy, guide communication across stakeholders, and help teams balance quality with delivery timelines. They also explore the leadership skills that make the biggest difference—from mentoring testers and managing risk to advocating for quality throughout the development lifecycle.
Whether you’re an aspiring Test Lead, a tester looking to grow into leadership, or a technology leader who wants to better understand the value of quality leadership, this conversation offers practical insights into how strong Test Leads help teams deliver better software.
Can’t use the player?
Listen to this episode on Spotify (opens in new tab)
Episode Transcript
Mike Hrycyk (00:00):
Hello everyone. Welcome to another episode of PLATO Panel Talks. I’m your host, Mike Hrycyk. And today we’re going to talk about being test leads. We looked back, and it’s not a topic we’ve covered before, but it’s a topic that we all strive towards. Testers really go on to become test leads. And our other listeners, well, we want you to know what to expect from a good test lead. So, we’re going to dig into that. Today I’ve brought in a couple of our testing experts, and for that, I’m going to let Sal introduce himself.
Sal Bugliarisi (00:25):
Hey, Mike. I’m happy to join this podcast. My name’s Sal. I’ve been with Accenture for 18 years. I’ve been in the industry since the early ’90s, and a big chunk of that time was in testing. Most recently, I’ve transitioned into a tech delivery lead role, so I’m involved as well with development, but I’m a huge advocate for strong quality, and I look forward to our discussion today.
Mike Hrycyk (00:46):
Welcome, Sal. Bhavya, can you introduce yourself?
Bhavya Bhatnagar (00:49):
I’m Bhavya Bhatnagar, working as a senior manager in PLATO. Currently, I’m engaged as a test lead with one of our clients. I have over 17 years of IT experience and more than a decade as a quality lead and advocate of it. I see testing is just not an activity. It’s more than that. Quality is a business outcome. So, as a test lead, this is exactly what we do: bridge the gap, monitor the entire ecosystem and deliver business value to its customers seamlessly.
Mike Hrycyk (01:24):
Thanks, Bhavya. You’ve segued nicely into our first question. And so, we’re going to level set and figure out what it is we’re talking about today. So Bhavya, how do you personally define the role of an effective test lead beyond just managing test cases and defects?
Bhavya Bhatnagar (01:39):
As the name suggests, test leads is not testing test cases or defects. It’s more than that. It’s shaping strategies, changing the mindsets, having a communication flow across the project, having a broader vision towards what is the end goal. Who are the stakeholders? Basically, nurturing the entire team together.
(02:04):
When I say as a lead, we see the ecosystem, I mean, from the start to the end, the quality assurance team is the one who should be or is involved mostly across the board. If I have to summarize it as a test lead, the very good example that comes to my mind is something that my husband often says, “Consider yourself as a conductor of an orchestra. They don’t play every instrument, but they are the ones who actually shape the score, cue the players, manage the risers, ensure the performance meets the composer’s intent and delivers it on time.” So, this is how I envision my role to make everything run smoothly.
Mike Hrycyk (02:52):
I love that analogy. I mean, it even extends to encompass if there’s some really hotshot violinists who think, “I don’t need a conductor.” They’re like, “I don’t need a test lead,” but in actuality, to bring the team together, you do. Sal, same question to you. How do you agree with what Bhavya said? Do you want to add to it?
Sal Bugliarisi (03:08):
Yeah, absolutely. And I agree. I love that analogy with an orchestra. That’s a really good analogy. What I would say then is, yeah, of course, beyond managing test cases and defects, which is going to be a part of it for sure, it’s really about connecting quality to outcome and enabling informed risk decisions. So, the test lead, he or she, helps the team and stakeholders understand where the risk is, why it matters, why it’s important for us to focus on the risk and what we’re doing about it. So, although the test lead will often get their hands dirty and do the work itself, it’s really about helping the business understand the way they’re going to solve their problem, where those risks are, and of course, why that quality matters.
Mike Hrycyk (03:51):
So, some people, I’m sure, when they think about becoming a manager or becoming a test lead, they think the role is all about paperwork. So, how much of being a test lead is paperwork like reports, tracking, statuses, etc? Back to you, Sal.
Sal Bugliarisi (04:05):
Yeah, that’s definitely a part of it. There’s no doubt about it. Any sort of leadership management position is going to require paperwork. I would say the best test leads are those that keep that documentation and reporting lean, making sure it’s purposeful as well. If it doesn’t help in making a decision or if it doesn’t reduce risk, which is what testing is all about, it’s probably not that important or maybe doesn’t even need to exist. But I would say that even though there’s a lot of paperwork, getting your hands dirty kind of work, I would still say that most of that status is best communicated through conversations. There’s always a lot of value when you’re communicating directly with a human-to-human conversation, it just brings that trust and confidence with our clients. So, yeah, I just want to add that even though you have to do a lot of paperwork and reporting and all that fun stuff, it’s really about having that connection with people.
Mike Hrycyk (05:00):
So, Bhavya, to build off of that, if there is definitely some paperwork that you need to do, and I think that answer’s pretty clear, is there still fun stuff in being a test lead? What is the fun stuff?
Bhavya Bhatnagar (05:13):
Okay. With this client, I have my hands into paperwork for almost 80% when I actually started with the project, because it’s huge work. It’s about the process that you put in place, the automated work that you can actually create in order to prepare those reports weekly, having those statuses updated correctly. So, having a good enterprise architecture here plays a very important role. In the beginning, it seems overwhelming, but as the time passes by, it is, I should say, right now it is 30 to 40% of my week that goes into paperwork. But that is very crucial and important because you are driving test strategies. It’s not paperwork of only reporting and tracking statuses. You’re the person who’s driving strategy. You are the person who’s test planning, analyzing the risks, putting the mitigations in places, or even structuring the whole set for the entire audience. And the audience is all the way to the leadership, to the governance team, to the sponsors of the project or of the program. So, test lead may look like it’s a very small role, but your reporting or your visibility actually is to higher up in the ladder. I should say, is test lead an interesting role? It is very exciting.
Mike Hrycyk (06:41):
And I mean, I think I would agree that even if you can get the reporting work overhead from 80% to 40%, that in and of itself, that challenge, I would find that fun. Alright, Sal, what’s fun about being a test lead for you?
Sal Bugliarisi (06:53):
Yeah, that’s a good one. Well, I mean, I love connecting with people. So, I love when we get new, especially analysts, added to a project and with the eyes wide open, and just the world is my oyster kind of personality. I would say that for me is the funnest is just seeing and enabling and helping new joiners get into this field. I find that to be just – I get a lot of joy from that. I guess you could also say it’s fun. I mean, a lot of people that get into this field are just detail-oriented to begin with. So, they just get a joy out of finding spelling mistakes, out of finding issues with anything. And it’s not even just in technology; it could be anywhere. So, I think a lot of people that really enjoy that in life are natural fits for this type of career. So yeah, I would say those are the things that I find most fun.
Mike Hrycyk (07:41):
So, that’s great. That segues nicely into the next question, Sal. So, you’re sort of giving me the second part of the fun, which is why anyone likes testing in general? Yeah. And that doesn’t go away. So, the question is, is there a mind shift change that you have to make when you transition from a hands-on tester into a test lead? And what does that look like, and how do you make that transition? So we’ll stick with you, Sal.
Sal Bugliarisi (08:02):
Yeah, yeah, for sure. And I totally agree there’s a shift. There’s no doubt about that. I remember in the early days when I first got started, I’m one of these people that notices details and everything. So, I was super excited to get into this field. But the biggest shift I would say is going from finding bugs, like you’re just constantly looking for problems and boarding those problems, to actually owning the quality outcome. That’s probably the biggest shift because now you’re responsible for that quality and you own that quality. So, as a tester, it’s all about individuality and being execution focused. It’s all about executing and finding issues. But as a lead, success is more bigger picture, right? It’s about enabling the team or helping to influence decisions, as an example. And of course, accepting managing the risk rather than having perfect coverage when you’re in a project. I would say, I guess in a nutshell, I would say it’s basically going from finding bugs, looking for issues and reporting them to actually owning the quality.
Mike Hrycyk (08:57):
I really like the way you put that. Bhavya, same question.
Bhavya Bhatnagar (09:00):
If I have to say about the mindset, it is clearly a shift from my testing to QA team delivery testing. The shift has to be, there is no my scope anywhere further. It is the scope of the program, the scope of the project. So, you have to think not as a task executor, but as a strategic thinker more. The mind shifts from not doing the work, but actually enabling someone to do the work. So, I need to enable my testers to find out the data, understand the process, understand the actors of the project, or even to the larger audience, to the business users who are actually engaging us at different instances, that this is not only for you who are just creating business analysis user stories. We have to literally think larger outside the box. It’s not you. A system can get integrated with 15 different applications. As a test lead, you have to actually broaden your mindset, display that, and shift your mindset to understand the technical depth of the solution.
Mike Hrycyk (10:08):
That’s really good. Both of you have talked a little bit about how hands-on it is still a part of it. And Bhavya, you indicated that when you came into the project you’re currently in, paperwork suddenly took 80%. So, there’s this idea that a test lead, I don’t think, is ever going to completely step away from hands-on testing, and you’re going to want to do that. And when you see, “We’re not going to make it, I’d better jump in. ” But how do you balance the idea that sometimes you’re going to have to be leading and not hands-on, and sometimes you’re going to have to do hands-on. And how do you avoid burnout from that? Bhavya, we’ll start with you.
Bhavya Bhatnagar (10:39):
Balancing hands-on testing with leadership is almost like you have to do both equally. It’s more about intentionally where you will value add more. So, in the beginning, my energy was all into crafting or putting the enterprise architecture in place so that we can create or auto-generate reports for most of the audiences. But as soon as that strategy and the architecture was in place, my hands-on testing was something that I really wanted to keep myself involved into. So, that’s where the idea comes in. What are the critical business risk areas where, along with engaging the team or engaging the testers, I should also delve my hands into. So, this is the area where I’ll add more value if I can quickly go and test certain key scenarios, or looking at the QA coverages for that matter, adjusting the QA coverages, or coaching the team. In all these aspects, my responsibilities were kind of intentional. Where and who needs more support from you?
Mike Hrycyk (11:42):
Sal, same thing to you. How do you balance the burnout?
Sal Bugliarisi (11:46):
Well, if we’re talking about burnout, I mean, there’s lots of things that people do outside of work actually to try to reduce that. But I would say, for balancing the hands-on testing with the leadership responsibilities? I would say the biggest thing, and sorry, but Bhvaya kind of stole my thunder there. I was going to say the same thing about focusing on the high-risk areas is critical, for sure. Also, I would say is to trust that you’re going to be able to prevent burnout while still being able to be technically connected. The only way that you can do that is by just being conscious of your responsibilities as a lead, but at the same time, bringing value back to the project.
(12:23):
It’s actually quite a difficult thing because a lot of people that transition from a tester to a lead enjoy the work so much, they continue to just be fully hands-on. Whereas others are so eager to become a manager that they just leave the testing behind. So, it can be difficult at times, I think, just depending on the person. So many different personalities. But yes, I agree completely with the previous comment. I would say focusing on the high-risk areas, maybe even like exploratory sessions, that’s another really good way to balance it as well. Or, even, I would say the most important, actually, of all would be focusing on where your experience adds the most value. Somebody that usually moves into a test lead role has a ton of experience over the years. And by focusing on those areas, it’s kind of like low-hanging fruit, get that out of the way early, and then be able to still spend some time with leadership responsibilities.
Mike Hrycyk (13:10):
Yeah. I mean, I think I agree with you both. I’ve spent a lot of time in my career being a test lead on different projects and so on. And in some of them, I’ve found myself disconnected enough that it was problematic. And you’ve got to remember that we’re the experts. We’re going to sit in rooms with stakeholders, and we’re going to help them make decisions. And if you don’t have enough in-depth information in your own brain about how things work, it’s going to be hard for you to advocate in the right directions.
(13:33):
And the other piece that I think is really important is you’re the test lead, which means when people have trouble, they’re going to come to you for help. And if you’ve never touched it and if you’ve never done it, you’re not going to be able to give that help. And you can hand that responsibility off to an expert, and that works on occasion. But part of the respect you build as a lead is by being known as that expert and being known that you are the go- to. And so that can be important. And now I’ve provided my own segue to the next question. I believe that a test lead becomes the major testing advocate for the testing role. What does that mean for you, Sal?
Sal Bugliarisi (14:06):
Yeah, that’s a very good point. I would say being a test advocate is basically what it really boils down to is representing quality at the decision table. It’s about ensuring testing concerns are heard early, framing that risk in business terms. So, making it consumable by the business, right? And of course, always challenging assumptions respectfully. Yeah. I would say it’s not about blocking releases; that’s not what it means for a test advocate in the testing role. I would say it’s more about making sure that decisions are made with eyes wide open, people being fully transparent, and really earning that trust as you just mentioned, so that people rely on you and know you to be the expert and really be that test advocate.
Mike Hrycyk (14:49):
We’re going to come back to that word trust in just a second. But first, Bhavya, what’s your own take on the test lead being the testing advocate? What does that mean?
Bhavya Bhatnagar (14:56):
Exactly the way Sal said. It is so important that on the tables that we sit, the credibility speaks through itself by the competency that we hold, by the consistency that we have shown across different projects. It’s why we have to advocate quality by just how credible our decision making is, or raising risks very early in the stage, or how early our involvement was important. It’s not that we were only involved in bug finding. We were also plugging and playing how different integrations once get connected towards solution, where it can fail or what can fall back. So, I’ll just reiterate the point from Sal, to continue, that we are not the showstoppers for any release to go into production. It is more having the framework that we have to make sure that the quality is speaking through itself and providing justifiable reasons why this release needs to hold because there is something grave here that we cannot move to production. Being the problem solver rather being a problem creator, like always come with the mitigation strategy. That’s what, as test lead, I’ve learned so far: it’s good that we create risks or raise risks, but we also come up with a solution.
Mike Hrycyk (16:16):
So, awesome. And so, I think you’ve already provided some answers for this next part of the question in what you’ve said. So, let’s put a scenario together where testing is missing some credibility, either with a developer, product owner, or stakeholder. You can pick which one you want for the strategy you’re going to have. What’s a strategy that you would use when you find that there’s a deficiency in that credibility and you want to build it back up?
Sal Bugliarisi (16:37):
Yeah, that’s very important in any successful project or program with any client. So, building that trust and credibility, I would say there’s sort of two aspects to that. I see it as the technical aspect and also the personal or human aspect. I mean, they’re both equally important, but I very much think that you need to have that human aspect to build the trust. So, it’s connecting with people and being able to feel like you have enough confidence and trust in that person that you can talk about anything, whether it’s within the project or not. Of course, it comes with the technical aspect, which I would say is understanding the system itself at a technical level, right? That’s going to build trust and credibility. Of course, raising issues early, not at the last minute. So, if there’s any problem, whether it’s at a very low level or program-wide, you need to raise that early. Being pragmatic, which goes along with the previous point. And then of course, framing the feedback around the risk and impact itself, like no blaming. I think people lose credibility very quick when it turns into a finger-pointing or a blaming game. When our stakeholders or our partners, our clients, when they see that the QA organization is a partner rather than an obstacle, a lot of times people think that QA is this really ugly, annoying piece at the end of the software development life cycle. When they see us more as a partner, then the trust follows naturally.
Mike Hrycyk (17:55):
How do you get people to understand that we didn’t create the bug?
Sal Bugliarisi (17:59):
Exactly.
Mike Hrycyk (18:01):
So, the next couple of questions, we’re going to dig into specific skills that you guys have. And part of me feels like, how can we even address this question? Everybody knows the answers. I’m going to ask it anyways. How do you decide what not to test when time, budget, and resources are tight? And we’ll start with you, Bhavya.
Bhavya Bhatnagar (18:18):
I’m just dealing exactly with the same issue an hour ago, so I’m exactly at that point. What not to test? And this actually starts way in the early of the SDLC. I think the assessment of risk comes in the start of the project, not at the tail end, where you’re actually testing. It becomes a matter of what test cases that you can exclude out of testing because there are low risks, but overall the solution or key functionality areas that are crucial for the business, that comes way in the start. And assessing that and understanding what is a must-have is something that you always bring along with. So, what to test and what not to test is decided way in the beginning. Now, if you are really at the end, and this is the time that we really have to understand what can go and what cannot go, I think it again aligns with how can we prioritize certain things over others, or how can you have a minimum viable solution ready to be delivered because we just cannot make anything else. Assessing the MVPs and running the show with it, I think that is the best answer that I can think of. This is what we do exactly, or this is how I participate in time crunches.
Sal Bugliarisi (19:45):
Yeah. I love this question because over the years, I’ve seen people find it so easy to prioritize. What’s very difficult is deprioritizing. Like finding those two or three things that you can actually move down the list instead of making everything be at the top of the list. I would say that I prioritize based on risk, for sure, risk, impact, and also, of course, the likelihood of failure. So, things that I consider, for example, are what would hurt the business the most, what area would be most damaging to the business or the customer. Also, what areas have changed? Where have things failed in the past, or where have things failed before? Any area that we identify as being low risk or unchanged or well covered by previous work, I think, are good candidates for reducing the testing.
(20:33):
The thing is that I would say the key is that these trade-offs, because you’re always going to have to make trade-offs when you de- prioritize anything, they’re very specific, explicit, and very well communicated, right? It’s not just a fluke; these are very well orchestrated and purposely chosen. So yeah, I would say just based on risk, and impact, and likelihood of failure.
Mike Hrycyk (20:55):
And I think it’s important to note that as a test lead, you can accelerate things by understanding these things and making decisions on the fly, but also be aware that you’re not the owner of understanding the priorities of the business and the areas that are priority for the business. So, leverage your product owner, leverage your stakeholders to understand that, but don’t leverage them to understand what testing is removable. You’ve got to balance those two pieces of information. As testing has grown, as technology grows, we have lots of different skill sets amongst people. We have lots of different skill levels. We have lots of different personalities and career goals, but as a test lead, you have to lead all of those people. So, what do you do to make sure that you’re mentoring and coaching testers across these spectrums and being effective at it, Bhavya?
Bhavya Bhatnagar (21:42):
This is a very interesting question because this is where we always land up to when we are at our performance assessment. We do land up here. I don’t think we should only focus giving feedback twice a year. This is something that we have to develop in an ongoing basis. The way I mentor the team or the way I work with the testers here is I do emphasize on their individual strengths, what they really have, giving them a growth goal that this is where you can actually thrive yourself to because this is all really you know about. Always giving them feedback, even the tiniest good defect that you could even find. Even today, we had a very interesting defect that we found, and in the triage, even the developer was amused to see, ” Oh wow, this scenario we could not even capture. So, giving the feedback there and then in front of the audience, promoting them, showing them that this is your treading path. I think these are the areas that you can always give them coaching.
(22:49):
The next area that I have very recently indulged myself in, and also pushing the team, is, of course, AI. How you can really utilize Copilot for your test creation? Do you really need to wait all the way till the end, or is this something that you can actually utilize? Write the right prompts, learn how to put correct prompting for only your testing purposes. This is your next career goal that you can think about. And I’ll just go back to one of our previous questions where how you put your credibility in space is where I think the world is changing from being a quality analyst to a quality software engineer. And I think that mind shift has to be there with everyone. So, I think learning by yourself before you actually coach these people is equally important.
Mike Hrycyk (23:42):
Alright. Anything to add to that, Sal?
Sal Bugliarisi (23:45):
Yeah, Bhavya covered all the important points there. Thank you, Bhavya.
Bhavya Bhatnagar (23:48):
For that. Sorry for taking up your time.
Sal Bugliarisi (23:50):
No, not at all. It’s great. I agree with you completely. I would say, yeah, starting off by understanding where somebody wants to go and what motivates somebody. That’s for sure key, right? Once you know what somebody’s goals are, what their aspirations are, where they want to go, it’s much easier to coach and help them grow. But the thing to also consider is that coaching is not like a one-size-fits-all, because as you know, everybody’s different, everybody has different personalities, right? Some testers thrive with structure, right? They really want to have everything clearly laid out, while others are much more autonomous. I would say I would use a mix of mentoring, even like pairing, like what do you call it? Shadowing and, of course, giving people challenges, and constant feedback. I think using this and balancing that with where somebody wants to go in their career will always yield a positive outcome.
Mike Hrycyk (24:39):
I think it’s important to remember that a test lead is a lead and not a manager. So, you’re not disconnected, you’re not a person sitting in an ivory tower just sending out status reports. You’re integrated with the team, which means, as you said, Sal, your feedback should be constant. It should come daily. If you’re not giving feedback four, five, or ten times a week, then people aren’t going to improve. That’s part of what your role is. And then something you said, Bhavya, is building people up in meetings is awesome. Negative feedback is private, right? So, try to make sure you have that balance. Shame-based coaching can be effective, but it does not build a team that’s cohesive.
(25:17):
Alright, great. I’m told that our time is coming to an end, so I’m going to jump to the last bit. If you could give one piece of advice to a new test lead starting their first project tomorrow, what would it be and why would you give that advice? And so, we’ll start with you this time, Sal.
Sal Bugliarisi (25:35):
If you give just one piece of advice, I would say to just really learn the solution or the product or whatever project that you happen to be on, and understand the risks before you try to change any of the process. If you jump in right away and you try to change things without really understanding the product and risks, it’s bound to not be a positive outcome. Because that credibility comes from understanding the whole context, right? So, once you know what matters, how the system behaves, where failures are happening, and where the client is experiencing the most pain, everything else, the strategy, prioritization, all that other stuff, it becomes much more easier.
Mike Hrycyk (26:14):
I definitely agree with that, but there’s a balance, right? So, the same as when you’re going to implement automation, find a way to make a difference fast so that people can see the difference. So, it’s the same thing. Don’t make changes just to make changes, but demonstrate your value as quickly as you can. Alright, Bhavya, what advice are you giving?
Bhavya Bhatnagar (26:34):
I would say for the first 48 hours, just sit and observe. Just sit in every possible team. Make yourself visible to everyone and learn first. Once you have learned enough, then change your mindset from actually doing to leading. That’s when you’re, again, leading back to our previous questions, your mind shifts should come into space. Once your mind shift is there, you are almost there as a test lead. Now, it’s all about being a successful test lead. So, I think the vision that you have, or the language that you speak with risks involved, the way that you communicate with all your product owners, your developers, your governance team, I think all of that will just fit in. Don’t try to fit a round peg in a square, just it would not.
Mike Hrycyk (27:30):
I think that’s great advice as well. I think as part of that, you should also start building relationships early. So, in your learning, in your observation, talk to people. Ask them questions that make you appear to be respectful of the knowledge and experience that they have. People like to be respected. They like to be valued for their experience. And so, it is part of your learning; you get to gather all of that together.
(27:52):
Alright, guys, that was a great conversation. I think we all agree that a good test lead is the cornerstone of a successful project. And we just have to convince everyone else in the world that this is also true. So, I would like to thank you, our panel, for joining us today for this conversation about being a test lead. Thank you to our listeners for tuning in. If you had anything you’d like to add to our conversation, we’d love to hear your feedback, comments, and questions. You can find us at PLATO Testing on LinkedIn, Facebook, and on our website. You can find links to all of our social media and website in the episode description. If anyone out there wants to join in on one of our podcast chats or has a topic they’d like us to address, please reach out. We’re always open to new ideas. And if you’re enjoying listening to our technology focus podcast, we’d love it if you could rate and review PLATO Panel Talks on whatever platform you’re listening on. Thank you again for listening, and we’ll talk to you again next time.