Dear Software Development Manager: A Letter from Your Testers

Dear software development manager,

So, your company just put testers on your programming team. That’s no surprise. Agile teams are integrated teams: Product owners, project managers, developers, testers, designers, and technical writers all work together to create business value. And while cross-functional product teams have been the norm for some time now, more companies are aligning their organizational reporting structure to match how products are delivered.

As testers, we see the trend of our jobs moving closer to development, and we think it’s a good thing. Consider us happy to be here.

Happy … but possibly a bit concerned.

There are a few potential reasons. It could be that we’ve had a bit of conflict with your team in the past. It could be that we’re worried we won’t fit in well. We’re apprehensive that we’ll be viewed as an add-on to your team, rather than a part of it. And we might be uneasy about our relationship with you, our new boss. You might be a bit concerned, too.

To make this easier, we thought we’d point out four things you should know when managing testers on your development team.

1. Conflict resolution is now officially part of your job.

Let’s be honest: Programming and QA relationships have a rocky history. Sometimes, it’s been downright bad. We’ve all suffered.

This is one of the reasons programming and QA have been isolated in silos—not because it wasn’t necessary for them to communicate, but because of the inherent strain between our jobs. Unfortunately, there’s been a lot of finger-pointing between teams, with a shameful amount of mutual disrespect that’s hurt both sides.

You now manage two groups that have a built-in reason to enter into conflict situations. After all, they write code. We find problems. They build systems. We break systems. They translate requirements. We identify unhanded corner cases.

When bad news is delivered, it’s easy to shoot the messenger. And it’s easy for programmers to feel judged when mistakes are pointed out. This makes conflict a part of our job, and now conflict resolution is a part of your job.

When we worked for a dedicated QA team, things were pretty simple. Each manager represented a team, and upper management expected you and the other manager to resolve conflicts however was best for the company. Your boss might now assume that because everyone works on the same team, there won’t be any more conflict.

But of course, that’s not true. It just means you’re left in the middle as the final decision maker. You probably used to negotiate with the QA manager, when you had the luxury of defending your team’s position 100 percent. You no longer have that luxury. You must consider both the QA and programming teams and portray a unified face to other teams, without throwing either internal group under the bus.

The conflict that used to be external is now internal. And you can’t let it pull apart your team.

You should spend a bit of time thinking about how you’ll handle conflicts in a way that preserves everyone’s dignity and respect and still does what’s best for the company.

2. You model how the programmers will treat us.

As long as we’re being candid here, we know that we all have “in-group” jokes. We used to tell the “How many programmers …” cracks. We had the Dilbert cartoons on our cubicle walls that poked fun at arrogant engineers. And we know you did, too. It’s human nature, and it helps us bond with each other. It’s all good.

But now that we’re here, everyone is watching to see how you will treat us. And the rest of the team will model your behavior.

We’re not worried that you’ll be mean or rude; you’re too professional for that. But we are worried that you might give more weight to the programmers’ ideas, or make their projects a higher priority, or invest more of your time into their training and success.

In short, we’re worried about being “second-class citizens” on your programming team.

You might think we’re being silly. But we see what companies value in the titles they create and the people they promote. We know that tech leads, software managers, directors, and CTOs mostly come from the software engineering group, not the QA group. We’re not suggesting that you can change this, but for us, it’s an elephant in our career path.

The programmers already suspect we’re testers because we couldn’t cut it as coders. Of course, this isn’t true: We’re testers because it’s a valuable job that we care about and we’re good at. We’re proud of what we do, so we need you to be proud of us, too. We need you to teach the programmers to respect us for the value we bring by showing you value us and investing in our professional growth, just like you do with the engineers.

Show overt respect for us in front of the group. Include us in decisions and conversations that affect the product. Ask us what we think in team meetings to show that our perspective is important to you. And, heaven forbid, if you “smell” any disrespect, hurtful joking, or side remarks that disparage our work, deal quickly and directly with these comments.

After all, we’re on your team now. Protect us the same way you do the other programmers, make us feel welcome here, promote our good work, and look for where we can become leaders on your team and in the company. If you do that, you’ll win our complete loyalty.

3. Give us a safe environment in which to do our jobs.

It’s 7 p.m. the night before a big release. The final build was done at 3 p.m., and we’re running through the test plan. The automated tests pass, but something doesn’t feel right, so we’re putting the system through its paces. There was this bug that we couldn’t reproduce a week ago, and we hoped it was gone. But now, we need to be sure.

Finally, we find it. Woo-hoo! We smile because we tracked the bug down, detailed the steps to reproduce it, and gave your team what they need to squash it. We file the ticket and send you an email.

Then you call and you ask the question we dread: “Can you sign off on the build anyway? We really can’t miss this release.” This makes us feel like we’re in an unsafe and unsupportive environment.

Please don’t pressure us to hide our work or delay entering the bug so you can make a deadline. That’s not fair to us or to your developers. You now take full responsibility for the delivery, so don’t ignore what we report or try to deny it. Instead, factor it into whatever decision you make. You can ship the software or hold back the release; that’s your call. But it is our job to help you make an informed decision, and we promise to do that.

Please also make clear that the decision was yours, and stand by it. If you choose to hold back the release, the developers may blame us for missing the deadline and see us as an obstacle. To use a baseball analogy, we’ll be the “batter” to their “pitcher,” and that puts us on opposite teams.

Instead, make us the “catcher” to their “pitcher.” We’re on the same team, and that means we win and lose together.

Oh, and if we’re there at 7 p.m. the night before a big release, we expect you and a few programmers to be there, too.

4. Don’t immediately ask, “Why didn’t QA find it?”

When bugs are found in production (and they will be!), don’t immediately ask, “Why didn’t QA find it?” We might be a bit touchy, so forgive us, but we’ve solely held the blame too often in the past, so we have some fears about it.

This might not be easy, because sometimes your boss will want someone to point fingers at. When that happens, everyone will be watching how you act. We’re happy to take shared responsibility with the developers for the problem, so please don’t hold the QA folks alone accountable. After all, we’re a team now.

Let’s Get to Work

Having testers on your team can make your developers much more effective. We love working with your programmers, and we’re excited to be here—but please realize we’ll be a bit on edge at first.

Thanks for taking the time to read this, and please chat with us more about it in our one-on-one meetings. (We do have one-on-one meetings scheduled, right?)

Oh, and remember: When we do have to work late, pizza covers a multitude of sins.

Love,
Your New Testers