Dear programmers, a few notes from your QA team lead:
We want the same thing.
We want the best possible product to go out of the door and our job is to make you look good, rock star good. Sometimes, you get in the way of that.
We don’t actually hate you.
Not by default, and not at first. It takes time and effort on your part to earn the ire of the QA team. But if you tangle with one of us, you tangle with all of us. We talk about you. We trade horror stories about that one bug that took weeks to fix because you stalled every step of the way. Yep, we remember that one well. You can redeem yourself, but it’s not easy.
Sloppiness annoys the snot out of us.
Like that zip code field in the database that only accepts ten characters, but we can enter 255 in the app? That’s something you should have thought of before you checked in the code. Spell check is your friend when you’re doing UI stuff. Think before you type.
You and I think alike, but we’re different.
You build it, we break it. Good QA people can program in your language, so we understand what you’re talking about, and we might have a suggestion as to how it could be done differently, or something you missed. Try bouncing ideas off us once in a while. Also, we may have an idea of what you’re actually doing, so lay off the BS about how hard it is.
We are extremely picky because we’re paid to be picky.
It’s not personal, it’s just how we are. Details are important and we care about all of them. Even the annoying ones. We also like the pictures to hang straight on the walls, and shoelaces to be tied neatly.
We don’t expect you to be perfect.
If you were perfect, we’d be out of a job. We know you’re not perfect, and neither are we. What we’d like is for you to accept that you’re capable of making mistakes and missing details, and stop acting like we’re out to get you. Trust me, if we were out to get you, we’d be waiting in the parking lot with pitchforks (we keep them in the server room, just in case).
We’re not perfect either.
Guess what? We make mistakes too! It’s OK to tell us when you think we’re wrong, but please don’t be a jerk about it. It’s not a contest.
We’re not frustrated programmers.
Yes, there is some cross-pollination between QAs who become developers and developers who become QAs. But there are also QAs who learn to code so we can test better. Not so we can escape QA, or because we covet your job, or because we’re bored. We learn so we can better understand how you built the app in order to find its weaknesses so the client never sees them. And so we can automate the boring repetitive parts of our day.
Just fix the darned bug already.
We don’t care about whose fault it is, or how hard it was to fix, or how Joe Coder did such sloppy work you have to refactor all his stuff to fix it (believe me, we already know all about Joe Coder). We just want the bug fixed so we can re-test it and get it out the door and we have no patience for whining.
Never, EVER break the build we’re working in.
Please make absolutely sure the app will both compile and run before AND after you check your stuff in. If you break the build we’re WORKING IN, we’re dead in the water till you fix it. We’ll come and sit in your cube and stare at you until it’s fixed and we can go back to work.
Test it before you send it to us.
If we can’t even get through the happy path, then dude, what were you thinking when you checked the code in? (See “Sloppiness annoys the snot out of us”)
If you don’t understand us, talk to us.
Sometimes we don’t communicate all that well. Some things just make more sense face to face. Come talk to us, we rarely bite programmers.
See you at the release party!
Love, your QA team.
(And yes, I really am a QA team lead.)
This was written in December 2010 when I was working on a very waterfall project for %GOVERNMENT_AGENCY%. My local team was assisted by a team of offshore developers and testers in %DISTANT_COUNTRY% that couldn’t program or test their way out of a wet paper bag with a jackhammer. Broken builds were a morning routine, bugs didn’t stay fixed, and the team had been handed poor design and architectural decisions we couldn’t challenge. You had to laugh at it.
See also Words to a new software QA