How a team lead sees an Ideal QA Engineer

TL;DR

You want quality, so do I, so do our clients. In software development, quality isn't just the QA Engineer's responsibility, it's everyone's. But as a QA Engineer, you are the ambassador of quality for the product. Here are some of the criteria I look for in an ideal QA Engineer:

Are you a Learner or a Victim?

You want quality, so do I, so do our clients. Quality isn't just the QA Engineer's responsibility, it's everyone's. But as a QA Engineer, you are the ambassador of quality for the product.

This topic came up during a conversation with Taia some months ago. We were walking around the streets of Iasi, discussing how I see an ideal software engineer as part of my team, when the discussion naturally turned to QA. I was saying that software engineers and QA Engineers too, need to be more flexible, take on more responsibility, and be more proactive. I also understand the frustration that could arise from such observations, too many times, managers say "be more proactive" without explaining what that means.

Feedback without actionable advice is just noise.

But here's the important choice:

do we choose to be a victim and complain, or do we continue growing?

Everyone grows at their own speed, but this is the first point I want to make about an ideal QA Engineer: they choose not to be a victim. They work with life as it is, not how they wish it would be.

• "The dev didn't announce it was ready."
• "The requirements were vague."
• "I didn't have access to the environment."
• "Nobody told me about this feature."

I'm not saying there are no things outside of our control. People make mistakes, requirements change, communication breaks down, these are realities of working with humans. But one thing we can control is our attitude. My ideal QA Engineer takes things as they are and asks:

What can I do to make this situation better?

They focus on expanding their area of control rather than complaining about what they can't change. They still get upset sometimes and speak up, but they understand that focusing on what they can influence is what makes them a great professional.

Does your manager support your growth?

Before continuing with my criteria for an ideal QA Engineer, I'd like to acknowledge something important: you might encounter a manager who is insecure or even toxic, someone who demands more from you but doesn't invest in helping you get there. Every initiative you take might be questioned, every suggestion dismissed unless it aligns perfectly with their vision. This kind of manager can really hinder your growth as a QA.

There are also good managers, firm but kind, who celebrate when their team members outgrow them. They know that their team's success is their success too.

You may find yourself in a reality where your proactivity could be hindered by the very person who is supposed to help you grow.

If you have a challenging manager, you can either remove yourself from the situation or slowly work with them, understand their concerns and motivations, and find ways to build trust so that your proactivity is seen as a contribution rather than a threat.

What a team lead looks for in an Ideal QA Engineer

Here are some of my criteria for an ideal QA Engineer. The list is not exhaustive, but it's a good starting point. As a manager, I believe in empowering people to work independently and make decisions. I value self-reliant people who can handle difficult issues proactively, even when there isn't a Jira ticket, a comment in a pull request, or a chat message guiding them.

I love to surround myself with people that I can rely on, without treating them like children on every single detail. I love self-assured people who understand their limitations but aren't scared by them, instead, they're motivated to learn and grow. I also know that people love being accountable for more difficult things if they had the time to grow into it.

I love self-assured people who understand their limitations but aren't scared by them, instead, they're motivated to grow.

1. Proactive ownership

I like having QA people who don't wait for a ticket to be assigned before they start doing their part. Don't get me wrong, I'm all for nice processes and documentation, but we don't always have a perfect flow. I appreciate people who don't sit idle just because the process isn't yet in place. When your Jira column is empty, that's not your cue to catch up on YouTube videos or discover what's trending on Instagram reels. Instead, I enjoy seeing people research tools and practices that could make their life easier and consequently, the entire team's life easier.

I like having QA people who don't wait for a ticket to be assigned before they start doing their part.

2. Accountability beyond their direct area

I like QA that try to improve things that are not in their direct area of contact. They know, or they feel, that if that thing is implemented or fixed, there could be fewer bugs, and they are not afraid to ask for it.

For example, they might notice that bugs are being discovered late in production because error logging is insufficient, or that the team keeps running into the same types of bugs. They don't know how to set up monitoring tools or automated tests, but they research solutions, understand the benefits, and propose implementing better error tracking, alerting systems, or automated smoke tests in the CI/CD pipeline. They bring concrete examples and data to show how this would have caught issues earlier and saved the team hours of debugging.

I like QA that try to improve things that are not in their direct area of contact.

3. Clear communication and regular updates

As a QA Engineer, you need to communicate clearly and effectively. You may need to understand technical terms that aren't part of your daily vocabulary, but that's okay, ask questions.

The ideal QA Engineer doesn't wait to be asked for updates; they provide them proactively. Frequent updates, even brief ones, are better than silence followed by surprises. As a team leader, I'd rather have more frequent updates than wonder what's happening and start chasing people down with questions.

Here's a pro tip: saying "I don't have any updates" is still an update. "Nothing new to report" is an update. "Still working on the same thing" is an update. Silence? That's just silence, and it makes managers nervous.

The ideal QA Engineer can communicate clearly and provide updates proactively.

4. Courage to challenge and improve

Taking note of the type of manager you have (hopefully a good one), I like QA Engineers who challenge me or other team members and push us to think outside the box. I like a QA who doesn't just listen in silence and execute what's told to them, but rather speaks up and breaks the status quo when it benefits quality.

An ideal QA Engineer isn't afraid to speak up about issues that might not be directly in their lane. They see the bigger picture and understand that quality is a team effort. They're willing to suggest improvements to processes, tools, or workflows that could prevent bugs before they happen. If something doesn't make sense, they'll say so and that's exactly what I want.

I like QA Engineers who challenge me or other team members and push us to think outside the box.

5. Learning a programming language or framework

I like having a QA on the team who isn't afraid to install the project locally and poke around to see what's going on. I don't expect them to implement features (unless we're talking about automation tests), but they should have a clear understanding of what technologies are used in the project, what they do, and why the team chose them.

They should be bold enough to add some code, especially these days when AI can help you with that. This will bring the QA closer to the developers, and that's a win for everyone. I'm also happy if the QA Engineer picks up a programming language from the project and goes beyond poking around to actually understand the more advanced concepts. Even spending a few hours a week exploring the codebase will give them a much better understanding of software development and help them in their QA work.

I like having a QA on the team who isn't afraid to install the project locally and poke around to see what's going on.

6. Guiding developers in testing strategies

Just as they should learn a programming language, the QA should also be the ambassador for the testing process and guide developers in best practices for testing. We know that each developer should test their own work, but honestly, no one can test their own work as well as they think. We all involuntarily take the happy path, the one that always works.

The QA Engineer should help, guide, and encourage developers to use specific patterns and techniques for testing. They should establish themselves as experts, as the gatekeeper of the quality of the product. They are not there to catch developers doing something wrong, they are there to help them build better software.

I like having a QA who helps, guides, and encourages developers to use specific patterns and techniques for testing.

7. Has confidence in themselves

I love having a QA who knows how to keep developers grounded and bring them back to reality when needed. Many of us developers fall in love with our code, admire our elegant solutions, and sometimes forget that there's this thing called "users" who need to actually interact with what we built. A great QA knows how to tap us on the shoulder and say, "The code is elegant, but users can't use it."

You might not know all the fancy design patterns or the latest framework trends, but you know something that's arguably more important: you know what it's like to be a user. Users don't care if you used the latest microservices pattern or if your code follows SOLID principles. They care if the thing works. You're an expert who systematically ensures that the product works as expected. Own that expertise.

I love having a QA with confidence in their expertise and the ability to bring others along with them.

8. Keeps caring

We always struggle in so many different areas of our lives, both professional and personal. There is no blueprint for success. There are many who pretend to know it, but they're trying to bullshit you. Try to stay true to yourself and hold on to what matters to you.

Be willing to change your opinion when new evidence comes to light, but you should have values that are important to you. Keep working towards the things that matter to you, even if your peers may say they're not important. If you feel that something is important to do as a QA Engineer, do it until you find out that it's not.

Be professional. Don't give up. Your passion for quality matters.

I love having a QA who has values that are important to them, but is also willing to change their opinion when new evidence comes to light.

Conclusion

Take my words with a grain of salt. I live with a QA Engineer under the same roof, so while I do know a thing or two about QA, I'm painfully aware of how intricate your domain is and how it's not as easy as it may seem.

I admire you as QA Engineers. As a developer and team leader, so many problems were solved because I had great QA Engineers around me. I had people who challenged me, people who made me get out of my comfort zone. People who helped me grow as a leader and as a person.

So keep doing what you're doing. Keep caring. Keep challenging. Keep growing. The industry needs more QA Engineers like you.

I admire you as QA Engineers who keep caring, challenging, and growing.