A Vigilante For Quality vs Bridging The Us VS Them Gap

We all have to start somewhere, even superhero vigilantes.

Earlier in my career, when I first started working with tech, I always wondered how developers solved problems. My first jobs in tech were customer service related. I took phone calls. I wrote up issues with products. I reported my own investigations. That's as far as I was allowed to go.

Then, a few years later, I was offered the opportunity to do something more around development. This was exciting to me because I found I had a passion for good working software, not because the company needed to have good working software, but because the poor customer service folks who had to explain poor working software to people that would call to ask for directions or who would find defects and report them. That was where my passion was when I first started in software development as a tester.

The Vigilante For Quality

My first year was akin to any superhero's first year. You think you are doing the right thing by taking names (aka finding bugs) and then finding the culprit. I hunted down developers with very little thought for how they would feel having someone tell them they made a mistake. I often found myself in heated arguments over defects which were regularly backlogged. I didn't understand why everyone else didn't see the problems I saw in the application. I didn't understand why they weren't as concerned as I was about the quality of the application we were creating.

You Failed This Software!

I often got comments and feedback later around these moments of engagement. I was too harsh. I wasn't thinking about the bigger picture. Or I was thinking too much about the bigger picture. I needed to change my tone. I needed to be less confrontational.

The other side of my superhero problem was I was willing to sacrifice my life, health, and general mental stability to see quality be a priority. To render quality as a tangible thing that could deliver as much, if not more value to the customer than any delivered feature.

No defect was too small, no effort too large. No building too tall... you see my point. Everything was a challenge and I was the quality hero that was going to nail it down, even if I had to do it all by myself.

This caused other things to happen around me. Developers were less keen to talk to me. People didn't like my absolute, black or white, yes or no nature. It works for some things, but not everything and certainly not with people.

Learning To Modify My Approach

It took a better part of a year, with coaching, to make changes to my approach. I still thought I was right. I still had a lot of these hard line values, but I tried to bridge the divide in some way. I approached people with suggestions instead of demands. I made more of an effort to understand the problem from a different point of view before attacking it like a planned mission on a criminal organization.

Leading in the Light of Day

While I didn't believe in what I was doing at first, doing it slowly made me change into less of a hardliner and more of a collaborator. I gained more awareness of situations because I was trusted to help understand and influence those situations. I was part of a team. I balanced being a defender of quality with empathy and understanding that people make mistakes. Perfection isn't the goal, but rather an ideal, and a poor one at that.

Having values over rules, but applying the rules when necessary became my focus. Understanding people and politics rather than applying some bad labeling has given me better approaches to how I advocate for software quality. Understanding whether to be a visible leader or to put on a mask and go rogue is a valuable skill set to have. You have to be prepared for the risk from both sides. You need to be prepared to fail at an objective to attempt it.

Fictional heroes fail all the time. Real heroes fail quite a lot as well. Those consequences can be pretty catastrophic depending on what you are doing. When you start looking at risk and collateral damage; you take a step back; you gather more information; you make a more informed plan of action. Mitigation is a hard skill to master, and it's even harder to put into practice when you have a lot of unknown unknowns.

The biggest lesson heroes and villains give us is that sometimes the world isn't so Us vs Them. It's really all of us together. It needs to be all of us together or none of it matters.

Bridging The Divide

Building relationships with people and disciplines that you would normally not think to talk to is a good first step. Removing the barrier of developer and tester collaboration is even better. Don't treat software like a double-blind study. It's not that kind of scientific experiment. It's a social one.

If you are afraid of letting your testers talk to anyone about what they are testing because it might taint their testing results, then you might be worried about the wrong thing. Testers should be talking with everybody, respectfully, to try to understand from their perspective how they think things should work. At the same time testers can share what they think they understand about how something should work. This gives people access to view points which can minimize churn, missed development criteria, and improper feature development.

Testers: Be visible with what you are doing. Demo you test cases. Demo the automation. Demo your thought process. Record your testing notes and testing sessions. SHARE, SHARE, SHARE. Demo a new tool set. Get a developer to help you optimize the automation test suite. Look for opportunities of collaboration (aka pairing) wherever you can. Don't feel like you have to take on the whole ecosystem of software alone. You have allies; you only have to ask for help.

Team work making the dream work!