How to be your QA’s favorite Dev (and why it matters)
Over the past fifteen years, I’ve been a Software Quality Analyst at six different companies. I’ve worked with more developers than I’d like to count. But when my current company asked for referrals to fill an open developer position, I only reached out to three. What made those three special enough that I’d stake my current employment reputation on them?
1. They test their own code
Wait, isn’t it MY job to test their code? Am I just looking for developers who do my job for me? No. Everyone’s time is wasted when I have to point out obvious problems. When I say they test their own code, I mean they have tested it enough to sincerely believe that all the acceptance criteria will pass. This means they do a quick run-through on the dev environment after it is built, to make sure they checked in all the components. This avoids many of the “it works on my local” failures. It also means they do a final read of the acceptance criteria to make sure they didn’t miss anything.
2. They document what they did
Nothing makes a QA’s heart sing as much as a detailed comment from the developer when they move the story to QA. That comment shows me that they double-checked the acceptance criteria, allows them to note any exceptions they had to code around, and even note things they DIDN’T change. Basically this comment helps me scope the risk of the change and how extensive my testing needs to be. They also include a summary of any questions they asked the business analyst and update the story with revised details. If you write this comment routinely as part of checking-in your code and moving the story to QA, it will be fresh in your mind and I’m much less likely to come ask you questions about it later. Win-win! (To earn bonus points in this area, throw in a SQL statement I can run to find test data or link to a related story that explains the history of the feature.)
3. They respect the process
I’ve worked with many enthusiastic developers who have lots of great ideas about new ways to improve our product or our process. I love that passion! But if you just implement your big idea out-of-the-blue one day because you were blocked on something else, you’ll get a lukewarm response (at best) from me. That’s because I’ve been around long enough to have seen these grind the team to a halt due to unforeseen complications. There’s a reason we write up stories and check them for completeness before starting. There’s a reason we have someone in charge of prioritizing them against all the needs of the business. There’s a reason we do technical design reviews with the team before we implement high-risk changes. Please funnel that passion into the top-priority story instead. The business (and QA) will thank you!
My favorite developers also show me they respect QA’s process. This means when I ask you to review my test cases, genuinely read through them and give feedback. When I mention that an automated test case failed, take it seriously. (I know false positives are a problem. Believe me, I KNOW. And over in QA we spend a lot of time trying to avoid that, but it still happens.) Finally, the best developers take responsibility for getting a story working, even if it was broken by another developer. Don’t make QA bounce back and forth, interrupting developers. Just say, “Oh, it looks like that was because of a change someone else made. Let me chat with them and I’ll let you know when it’s ready to test again.”
4. They bring baked goods
Okay, so I’m half-joking about this one, but one of my favorite developers showed up with this pie one day. Instantly my favorite developer! Why not bring in donuts when that stressful release is finally shipped? Or make extra of something on the weekend and bring it in just because? It doesn’t even need to be food. Just every now and then, do something that shows you were thinking of the team in your off-hours.
So what?
So, why does it all matter? Shouldn’t you worry more about what your boss and your peers think of your code? Well, it matters for your current role because the whole team will be more successful. QA can get through more stories, and they can do more exploratory testing beyond the story. They can find integration issues and workflow issues. They have time for cross-browser testing, security checks, and verifying the release notes and documentation. They can look for inconsistencies in the product and improve the overall user experience. In short, you will be a member of a team known throughout the company for delivering on-time and high-quality software.
Why else does it matter? In time, team members will move on. And then being your QA’s favorite developer means they will open doors for your career. At my last position, the Development Manager randomly called over the cubical wall to me one day. “Hey, I just got an application and he says he knows you. Tell me about him.” I replied, “Oh, he’s great. We want him.” “Good enough for me,” said the manager. “I’ll set up an interview.”
