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.

Resistance is futile.

When your company has been acquired it’s a lot like being assimilated by the Borg. You hear rumors for months about some acquisition “boogeyman” who is lurking just around every corner. But then one day BOOM, an email drops and you have been taken over by this other corporate Borg cube which demands you conform to their ways and become one of them.

Acquisitions are not a quick and painless process. They are a long, drawn out and PAINFUL operation where the acquired company is taken apart bit by bit and rebuild in the image of the “Borg Corp.” With our recent acquisition we’ve gone through a rebranding of the companies fusing both of us under one flag with a name that sounds like an erectile disfunction medication, and a logo drawn by a third grader. We’ve have been sung the praises of our new collective in an infomercial style town hall where one of our presenters hawked their book at the end. We’ve been given the company rule book and have been to become obsessed with the company “values”. At another company I worked I was told to live and breathe our corporate “values” which left a pit in my stomach the size of a bowling ball. I don’t think I would ever want to meet someone who was obsessed or lived and breathed those “values”. If I was left alone in a room with that person one of two things would happen. Either they would “Stepford Wife” me to death with fake pleasantries and never-ending surface joy or they would straight up stab me in the back whispering, “One less person to get in my way.” Neither has a happy ending.

Along with the assimilation comes new (or old) technology. Depending on the evolution of the “Borg Corp.” you could either take a giant leap forward into the future of software development, QA and automation. Or you could be handed abacuses and told you have a major project due in two sprints. We were a smaller company, so we were easily swallowed up by “Borg Corp.” where they have begun the slithering their technology into our daily digital lives as soon as they could. One way they’ve done this is by giving us “new” laptops. I’m not quite sure where “Borg Corp.” buys their equipment but in the case of these laptops it’s pretty obvious they raided IBM’s garage sale. I don’t think I’ve seen a red dot in the middle of the keyboard since the late nineties. I’m waiting for the day the laptop says, “I’m sorry Dave. I’m afraid I can’t do that” when I try to run a SQL query. I know, I know I’m mixing my space genres but hey these are ridiculous times.

All in all, with any acquisition it’s a game of “wait and see”. You never know what’s going to happen really and you’ll drive yourself nuts trying to predict the future. Like the Borg, the larger company assimilates as many as they can wearing them down until they’re useless drones who can recite the “Borg Corp.” “values” like the alphabet and then they discard what they don’t need like refuse out of a starship. At this point in our assimilation, it’s anyone’s guess what might happen. All I can say is, “Resistance is futile.”

Confessions of a Disillusioned SQA.

One of the first jobs I got right out of college was working on a technical support line for (at the time) a very well-known photography company. Trying to explain what it was like working as a Customer Support Representative (CSR) is like trying to explain to someone what it’s like going to war. Unless you’ve been through it you don’t understand. I may exaggerate a bit but not by much. As a CSR you are the face and voice of the technology and company you support. You are at the front-line defense in a battle to maintain your company’s reputation in the marketplace. You are the tech savvy foot soldier in a never-ending battle with the enemy who are out for blood and who will not stop calling! Otherwise known as your customer. While on the line you’re eating, speaking, breathing and bathroom habits are not only controlled by how many of the enemy you engage in an hour but also by the call center commanders who have you under constant surveillance. These technical management figure heads are allowed to roam free and bark orders at you while you’re leashed to a device which spews bile at your soul 8 hours a day. It’s the kind of job that can easily break your will to live and I did it for 2 ½ years.

That job was my introduction to the upside world of software and product development. A place where there are “aggressive” schedules, and everything is “as designed.” I’ve been working in the software and tech industry for over 15 years now. In that time, I have seen, heard and experienced things which can only be described as, “That’s fucked up.” Along the way I have collected some stories which I hope you find funny and familiar. Some of these events I have experienced first-hand. Other friends have shared with me during marathon happy hours after a long week in the silicon mines. Each week I will post one of these tech tales and pull the curtain back from our dysfunctional development process. Fair warning, the names have been changed to protect the innocent and smart people who have some common sense and get things done. Some of these stories go as far back as the heyday of AOL and Compuserve or as soon as the inception of the AGILE process. So much like a Scrum Master’s (formerly known as Project Managers) backlog don’t expect a linear timeline. I’ll just rank it a priority and post it. See all you “team players” next week!

More Agile, Less Waterfall…this time.

Much like an “aggressive” schedule to move a new software into production, I also missed my release date several times! I have started and stopped this blog since January 2017 with nothing to show for it acting like a third-party vendor. I would have continued with it but with the lightspeed advancement of technology blogs have become almost irrelevant. Looking back at my “methodology”, I was taking more of a “waterfall” approach rather than adopting Agile/SCRUM. Which, as we know, is a far more efficient method for developing almost anything, when it’s done right. Unlike “SAFE” which is just waterfall in SCRUM clothing. And unless you’re stuck trying to herd a bunch of “legacy employees” who have been doing the same thing for twenty-five years to close just ONE of their tasks in a sprint. Then, well…that’s something for the retrospective.

It is my hope to complete a new entry at least once a “sprint” (short sprints, once a week) and post it here for a review. Now there may be times I may have rollover into the next “sprint.” I will try my best to be as consistent as possible to provide entertaining stories of my experience working in the IT realm and all the absurdities that come with it. Hope to see you at the next review!