Being a Quality Assurance Analyst doesn’t mean being an A**hole
When I first started QA, it was in an acrimonious environment where the developers and testers were pitted against each other. Think Sharks vs. Jets or the Empire vs. the Rebels or even Batman vs. The Joker. It was ugly and it made for an uneasy, inefficient, and tense work environment.
At Marxent we use the Agile software development process which allows for a more mature partnership between developers and Quality Assurance Analysts though it still takes work to keep things happily humming along.
Here are 4 things I’ve learned over the years on how to QA without being an a**hole about it:
1. Don’t be so judgy
I never judge developers when I find bugs. There was a time when I felt critical of developers who had introduced major bugs, but I found eventually that it was counterproductive and false thinking. A turning point for me was when I was working with a genius dev who I am certain had a 150+ I.Q. After I found bugs in his code, I thought, “If that guy can make mistakes, ANYONE can.” The trick is to always to focus on making great software and never on why it’s wrong or who coded it. My approach is to do my part as a teammate to help bugs get fixed.
2. Little things matter, but big things matter more
I know that not every bug is earth shattering, and that I need to keep the entire project in perspective. Even when a tiny typo keeps staring at me and driving me nuts, I try to put myself in the Project Manager’s shoes and keep the end goal in mind. I always pick my battles carefully.
3. “Your words wisely choose” – Yoda
It’s amazing what a difference your choice of words can make. I used to submit bug reports without putting a whole lot of thought into how they were worded. As long as I communicated the issue with clarity, I assumed that was good enough. But it’s not good enough. When you are telling someone they made a mistake, it is worthwhile to stop and think about the language you want to use to communicate your findings. As a rule of thumb I try to focus on actionable instead of qualitative language. I always ask myself, “If I had made a mistake and someone was providing feedback to me on my job, how would I want to receive that feedback?”
Here’s how: I get very specific, provide as much detail as possible and avoid generalizations that might come across as being pejorative or negative. There’s a big difference between, “The user’s name is wrong” and “The user’s name is displayed in the incorrect case.” Steering clear of negative words like “wrong” or “doesn’t make sense,” helps me to keep the developer’s focus on making great software.
4. Don’t be a Debbie Downer
As a Quality Assurance pro, your whole job is to point out all the stuff that’s wrong with other people’s work. To avoid being a Debbie Downer, you really have to maintain a good attitude. I always try to stay positive and be as helpful as possible. Does it work? Most of the time it does! It makes me so happy that I can do a job like this and walk away without people resenting me for pointing out all of the mistakes in a piece of work.
It took me a while to get to this point, and I’m still learning how to communicate better and interact with people in a way that fosters teamwork. It’s a challenging and rewarding role. As long as you’re not an a**hole about it.