I describe QA as my ideal role within a software team because I get to have my grubby hands in every cookie jar. I get to discuss business requirements/goals. I get to help evaluate code architectures, and I get to identify and run tests at all levels including usability. While I think this is awesome, it does mean that I am at risk of trampling on what other people view as their territory. This can lead to the age old thought process that testers are just negative problem finders who take pride in highlighting the mistake of others. So when I join teams and start communicating and challenging in all of these spaces I tend to see a fight or flight mentality take hold. In this case “flight” means finding ways to circumvent me. Not inviting me or holding meetings at times I can’t attend, withholding information until I come across it, etc. But it is the “fight” that I want to examine for a second longer.
Since I am perceived as highlighting other people’s mistakes, they then want to highlight mine. As boldly and proudly as possible. For example, I have had people raise bugs on signed off stories in stand-up just to make sure it is as public as possible. In cases like this, so much of my testing community self wants to shout “Wait! Stop! Testing is team ownership! Don’t just blame the testers!”. But the thing is, that won’t actually solve anything. Do I care who found the bug? Or just that we as a team caught it before our customers were impacted? Keeping in mind the end goal, I instead show my enthusiasm for their find. I ask them to show me how they caught it. I show them how to write up the bug report. I encourage them to help me put in better checks so that this type of issue won’t happen again.
It may take a few times of this, but before long I find team members from all roles are enthusiastically testing and raising concerns. I also find that they are much less concerned when someone else on the team asks questions about something traditionally in their arena. And just like that, every person regardless of their role, can have impact and add value to all activities within the Software Development Life Cycle (SDLC).
So in my roundabout way, let’s get back to this idea of culture over community. I would challenge every team member to leave their individual egos and narrow role definitions at the door. It is only by opening our minds to inputs from all team members that we can attain a culture of “building quality in”.