Quality Analyst (QA) is a new role in the Ann Arbor office, and most in the office haven’t worked with QA before. Being the person who reviews software looking for errors, or ways to improve the software, can make you as irritating as the boss in Office Space, who is always asking for more.
Having the right mindset will turn unwanted news into a well-received gift. There are four things to keep in mind:
- Everyone is working toward the same goal.
- Developers and QA have different mindsets.
- Acknowledge good work
- Shared experiences outside the job
Everyone is working toward the same goal.
First, know that everyone is working towards the same goal. At Atomic Object (AO), the goal is to build software that delights users.
An analogy for good quality assurance is someone reviewing your resume. When you create your resume, you write it and own the whole thing. You go through it when you are done. But you don’t send it off to your dream job posting without having someone else review it. Someone who will point out errors and suggests ways to make it better.
QA review feedback is intended to find errors and make suggestions for a better user experience. Since quality is subjective, working with the developer to understand whether or not something IS incorrect means you aren’t pointing fingers or playing the blame game.
Developers and QA have different mindsets.
Reviewing work means coming to the work with a different mindset. Developers are focused on “Happy Path” (software that works as intended), while QA considers “The Scenic Route.” (This is the term my mom used when we took a wrong turn or had to follow a detour. We weren’t lost, but we weren’t taking the most direct route to our destination.)
A number of issues are the “edge cases” around how a user might do something differently or unexpectedly. Ideally, this doesn’t cause the software to crash or cause any issues with the data (bad data, showing too much or too little data, etc).
You must acknowledge good work.
No one likes a person who only has negative things to say, so say something positive too! The shared goal of software that delights the user means it feels good, easy, intuitive, and just plain FUN to use the software. Point out great designs, fast execution, software that handles all the edges cases you can throw at it. Compliment software that handles the complexity and works. People want to hear good things about their work, and QA is in a position to see it and share that back.
Share experiences outside the job.
Finally, it’s important to develop good relationships with teammates. In sports, both the winners and losers walk off the field, then head to the local pub to eat and drink together. That builds bonds that exceed something the individual plays. Personally, I tell bad/dad jokes and bring in homemade cookies, as a blatant method of buying goodwill.
AO also encourages pair lunches and hosts monthly activities, to get to know everyone in the office, and I’ll be going to a conference with a group of developers soon. These activities are shared experiences evoking positive feelings between the developers and me. This way, they know my heart is in the right place and that I’m providing critical feedback on the work and not the person.
I love my job, finding ways the software isn’t working as intended before the client does. This could cause a hostile relationship with the developers creating the software. But, sharing the goal of delighting the client, providing positive feedback, and getting to know the developers as people (as well as bringing cookies!) helps me share critical feedback without developers taking the feedback personally and resenting my efforts.