QA is your window to the world.

In one of my previous jobs, I was in a development meeting for a new project which was ramping up and scheduled to release the following year. No sooner did I sit down when the Lead Developer next to me says, “Why are you here?”

I explained to him, “I was invited.” Mind you the meeting hadn’t even started yet.

He replied firmly (and with condescension), “Justify your reason for being here!”

Needless to say, I was shocked along with the other people in the meeting who overheard his statement. At that point all I could do was take a deep breath and take a stand in defense of myself.

I replied with incredible clarity and precision of words (like Julia Sugarbaker on the warpath), “You’d like me to justify why I’m at this meeting? Fine, if you THINK there is no justification for me as a software tester to be present in this meeting I will leave. As a matter of fact, let’s take it one step further not only will I leave this meeting but I will not conduct ANY tests on the product you are about to create. If you believe QA needs to justify their seat at the table, then you MUST be incredibly confident in your coding skills so you don’t need us, right?

But I think you should know that ANY defect, UI discrepancy or failure that makes it into production is YOUR responsibility! You fancy yourself a “master” of coding then have at it! Nooo, you don’t need us because everything you produce is PERFECT, right? Then I will pack up my things let the Project Manager know (who was running the meeting by the way) testing is not require for this project because you got this. I might also make the suggestion that any technical support calls that come in about this product get routed directly to you. Then you can explain to the potentially hundreds of users who will call in how their issues must be their own stupidity because you handed them a “near perfect” product so could there be an issue? So sir, I wish you good luck and god speed.”

I gathered up my notebook and started to leave when the Project Manager spoke up, “I invited him. Now SHUT UP!” With a smirk I calmly returned to my seat and the meeting began.

I think it’s an open secret that software developers can at times be narrow minded and somewhat arrogant. This does NOT apply to everyone in the development community but there are some who think they’re one step away from God and shit rainbows. You know who I’m talking about, right? Those developers who think the sun doesn’t rise until they wake up and they spend 24/7 coding FOR FUN! Usually in a dark room, unshowered and hopped up in Monster. Those “it’s a feature”, “It’s working as designed”, “can not reproduce” developers blind to the real world and only see things in ones and zeroes. They’re the reason why QA exists.

Quality assurance testers are the eyes to the world for the blind coder. We have to translate and navigate the “real world” for a group of people who rarely interact with it outside of their own community. It’s like explaining human behavior to a toaster.

A toaster’s sole purpose in the world is to toast (or burn) things. Same with software developers, their sole purpose is to crank out code. Unfortunately, at an early age their view of the world at large is narrowed to a pinhole. Their window to the world is usually no bigger than the monitors they use or their phones. They spend most of their time accessing these “portals” perceiving themselves to be “out in the world”. This limits their social skills because everything is in 2 dimensions and when you touch something no one slaps you and calls you “pervert”. Although with technological advancements those dimensions may have bumped up to 3 or 4. Most of their human interaction are with others of their own kind. So, they’ve been tasked to create something for which they are mostly unfamiliar. That’s where QA comes in. It’s our job to help development to take their blinders off and see the whole wide world. At times developers can take the “defects” (I prefer bugs myself) as a slap in the face to all their hard work but really what we’re trying to do is make them look better. Sure they’ll throw up terms like, “as deigned” or “it’s a feature” like Enterprise shields. But it’s up to us to take down those shields to produce a better product and help them become better creators. Developers can be like mechanics who never learned how to drive. It’s up to QA to tell them to keep their hands at 10 & 2 and show them where the brakes are.