informa
14 min read
article

Confessions of a QA Tester

Two years ago I joined a major development studio as a QA tester. Since then I've seen the economy bottoming out, studio-wide layoffs, a franchise under fire, and a team trying to keep it together. This is a success story of not getting fired.

       Two years ago I joined a major development studio as a QA tester. Since then I've seen the economy bottoming out, studio-wide layoffs, a franchise under fire, and a team trying to keep it together. This is a success story of not getting fired, this is the confessions of a QA tester. 

Inception

I started out as many QA testers at the company I worked at do, in a large room filled with dividers shaped into long desks I can only relate to as troughs. Entire teams sat at these desk-troughs, working with equipment in various states of antiquity and disrepair. It seems the company I worked for believed in a hand-me-down principle when it came to their technology- with the oldest tech ending up in QA. 

But, I was here to make myself stand out. And stand out I would, as I went to work being the very best QA tester ever. The project I worked on had just declared Alpha, and was very buggy. So for the next few months I worked at putting myself on the top bug-finder list. Due to the state of the game, it wasn't that hard to achieve.

Being one of the best started paying off, and I was selected to be an embedded tester. Being an embedded tester meant I worked with developers, clarifying issues for them, basically acting as support. All the while filtering requests from the QA team to the Dev team, coordinating with both teams as best I could. At some companies I hear embedded testers get paid more, which would make sense, seeing as how they do more than a regular tester does. But not at this company. Regardless, I was happy, because I was moving up with the devs. I could already taste a shiny dev job. 

Eyes Open, Mouth Shut

The first few weeks working with the devs were terrifying. Never having a job working with developers before, I didn't know what to expect. Up until then, working with devs had just been a distant, unattainable dream. Now that I was in the thick of it, I didn't know how to act. So, I adopted a strategy of learning everything as fast as possible without stepping on any toes. Thankfully my direct superiors took me under their wing and showed me what was, and more importantly what wasn't, proper behaviour in the studio. 

Its important for me to mention that the divide between 'Dev' and 'QA' was very large, and the disconnect seemed more apparent now that I was working directly with the devs. It's hard to explain what this disconnect is, or how it's displayed, but there was no mistake that QA had a place here, and that it was decidedly under the Devs. More recently the studio has started to remove that gap, with the remaining management acknowledging that a game with integrated QA support has less chance of being a broken, unpolished, piece of crap. It's a harder lesson learned than it should be. 

Whatever the disconnect between QA and Devs may have been, I was determined to keep going, and keep being useful. And useful I would remain. As deadlines started to loom, I started taking on more and more responsibilities. Soon I was the go-to guy for any online issues in the game. The game was constantly in flux- one thing would be fixed, another would break. New content was being integrated on a daily basis, and pretty soon there was multiple builds a day. With big changes came big problems, and as the 150+ team clambered toward release, the OT started.  

Overtime

What actually happened during overtime is now largely a blur. But from what I remember, it was too often, too long, and too stressful. This wasn't something I was unfamiliar with, I had learned the joys of overtime in college. My philosophy at the time was that since I wanted to work in the industry, I needed to demonstrate that I was a "clutch" worker. That translated into never saying no to OT. Say what you will about standing up for your rights as a worker and balancing the work/life relationship, but my work was my life. Being in such an expendable position meant that I can either do OT, or I can get my walking papers. Besides, since my regular pay was basically an unlivable wage, the chance to make time and a half was a welcome one. 

So I did the overtime, then I did it again. And again. And again. Pretty soon I started coming in on weekends. It started feeling like I was the first one in, last one out. The QA company I worked for was contracted out by the studio, and this QA company was draconian about being on time every morning at 9 am regardless of circumstances. No one cares if you worked 'til 12 hour shifts all week- you got paid for it, so you will be here on time or your five bosses will harass you all day. But, placating HR/middle management is just another part of being successful, so I came in on time, regardless of burn-out. 

The last few weeks were probably the hardest, for everyone on the team. Tensions were running high and fuses were short; Infrequent outbursts of frustration directed at me (or QA in general) started happening, but I continued to do what I was doing and I did it with a smile on my face. This has been a recurring strategy I have employed to break into the industry: Constantly strive to do as much as one man can. It's a lesson that needs to be learned quick for anyone still trying to break in- Its not nearly enough to do just your job. You need to do your job perfectly, then you need to do three other peoples job perfectly. Then you need to fix any mistakes made by your peers. All while not exactly knowing how something is supposed to work or who is responsible for it. If sounds stressful, and it is. Unfortunately, this is the only way to position yourself when you don't know anybody that 'likes' you. 

Finally, the game went to certification. If you don't know what certification is, you'll learn quick when you get into the industry, even quicker if you're in QA. Amazingly, there wasn't any issues coming back, and I was actually able to play the game I had been slaving over for months on end. Somehow we managed to get a first time pass on all major platforms, and we we're celebrating a critical success.  

Everyone's Moving Up... I Mean Out

Unfortunately, the game was not as successful as we were hoping. The critics hazed us, and in retrospect, rightfully so. The game was like a B movie that was too serious to be funny, and sales, although impressive, were missing expectations. Indignant and in denial, the team started planning out the next games. Which meant the QA teams started creating test plans (which is QA code for lots of sitting around, surfing the net, and Starcraft LAN battles). Things were looking good. My boss/mentor was moving into a production job, I was getting his job, and other embedded testers that had also broken their back getting the game out the door were moving up in similar fashion. 

Then something ugly and well documented happened. A bubble popped somewhere deep in the bowels of the global economy, which somehow made the entire thing come crashing down like a house of cards. The economy tanked, along with the bloated stock price of the studios parent company.

        At first, it seemed like it didn't affect us at all. Denial manifested itself in the belief that we were in a recession-proof industry. This might even be true- if development costs weren't so high, not to mention the risk involved in such a hit driven market. So, albeit the concern that our game didn't sell as well we were hoping, everyone was feeling secure, and no one noticed as the axeman cometh closer.

One night, on my way home to work, I got a call from my HR rep (this is never a good sign). She ambiguously told me not to go to my usual workplace, but to return to the communal QA area (the desk-trough building). Terrified I had been let go for some reason, I went to work the next morning shaking in my little QA boots. But, I wasn't let go. In fact, due to pure luck I was completely safe from the axe. Being a poorly payed contractor with a separate company has its advantages, and it's the fact that I was payed so poorly compared to the output I generated that I was safe from the layoffs. However, others were not so lucky. 

In the months following the layoffs the horror stories started coming out. Allegedly, employees who were to get the axe got a meeting request for the next day, while everyone else was told not to come to work. The unlucky filed into a large meeting room, where they waited (apparently while IT removed their access to email, computers, and disabled  passcards). An exec came in, and gave a heartfelt apology that this was happening (which was sincere, from what I hear), then another exec filled them in on the details on how exactly it was going to work. 

As for me, I was tucked away with the rest of QA, weathering the same storm the whole industry was facing. Soon things stabilized, and we went back to work for a smaller, more 'economical' team. 

First You Get Good, Then You Get Agile

As the studio moved forward, so did I. By now I had carved myself a nice slice of responsibility. I was an important part of a small team, I had low oversight from my contractor superiors, which allowed me the freedom to really maximize my use to the studio. My philosophy still in effect, I looked for a way to be more useful than I was before. Thats when we made the switch to Agile.

When a team switches development philosophies, there are going to be problems. Thankfully, one of my strengths is identifying weaknesses and finding solutions to problems they create. One of the problems my team was facing was a disconnect between a User Story (something a user does or experiences while using the product) and the technical tasks to make that story work. The root of the problem was the fact that we had all these User Stories, with completion statements and edge cases written out, and all these technical tasks with estimates and requirements, but no way to join the two.

So I took initiative, taking all the User Stories and tasks and connecting them in a spreadsheet. For an experienced manager this may not sound difficult, but for a QA tester with no real knowledge of Agile development, and little direction from management, it was a bit of a stretch. But, I pulled it off, and with that spreadsheet I was able to show the managers where the weak spots were, and how we could improve. It took a few sprints before the tasks were written out in a way that was easily filed under a user story, but that's how Agile works- things improve (theoretically) every sprint. 

  As our team evolved, so did that spreadsheet. Soon I was able to track the progress of all user stories, then track the velocity of the team, down to the velocity of each developer. Each new addition to my sprint tracking document was in response to a problem I was seeing. If the Devs were being piled on by too many tasks, I started to track their velocity, or if management was surprised that a feature was falling behind, I tracked the progress of the user story. Each problem was an opportunity to learn more, and gain more responsibility. 

Dissatisfaction 

  Some of you may be asking why I would be the one to be tracking sprint progress. Why I would be the one figuring out why stories were falling behind, why I was figuring out developers velocity. At  least, I started asking myself these things. I thought this was what the project managers did? Don't get me wrong, it's been my dream to be a producer, and I figured I was lucky to get into a position where I did a project managers work... But, I was a QA tester. More importantly, I was paid as a QA tester. A QA tester doing project management along with being a one-man test team. And this is when I started becoming dissatisfied. 

Things started to snowball after our next major launch. The mistakes were piling up, and the design decisions were... questionable. There was no documentation for the things being designed, so, true to style, I started to document the features being laid out  (since I've always wanted to be a designer too). I figure I could turn the mistakes into opportunities to show off my skills. So, I was documenting things as well as I could. That is, of course, until I made my first real mistake: voicing my dissatisfaction. I started raising obvious issues to shoddy design, mentioning the problems that were going to come up, identifying the weaknesses and raising them accordingly. Then, somehow, magically, I stopped receiving meeting requests. Somehow, magically, I was falling out of the loop. I was being forced out by the very people I was raising the issues to. 

Thats when I lost interest. Thats the exact point I stopped caring about what I was doing. Thats when it became about the paycheck. Up until that point the only thing that had kept me going is the unwavering belief that I what I was doing was important, and what I was doing was helping make the product the best possible product ever made. Having a game of the year mentality is important in this industry, and I lost that by being shunted aside for asking too many questions. And I wasn't the only one, others were seeing the writing on the wall, that it was just a matter of time. 

So I started looking for other jobs. Thankfully I had put out enough of an impression with devs who had since moved on that I was able to get a few interviews (along with sparkling recommendations). I couldn't quit outright, as I was living paycheck to paycheck  (which doesn't help with a workers satisfaction leve)l. Since I had become embittered, my focus shifted from being the best I could possibly be, to placation and delegation.My philosphy shifted from doing as much as humanly possible, to doing as little as possible and making it seem like I was working. 

Let me tell you its not something I wanted at all. But if you pay someone shit, and stop them from being able to grow professionally, and ask them to continue that job for at least four years or more (when my manager said this to me it took all of me not to outright laugh at him), all the while continually forcing them out of the loop because they ask too many questions- that person is going to get bitter.

       So, after months of looking for a new job, I finally found one with a smaller start-up company. And I'm already feeling much better- reinvigorated and wanting to do as much as humanly possible. I've been lucky enough to be put in a position where once again I can do the job I want to do. Only this time I'm actively encouraged to do so, instead of placating the middle management in order to wiggle my way into a position where I can be useful.

      I don't know what the moral of this story is, or what you're supposed to take away from this, or what the point of this article is in the grand scheme of things. Whatever the point may be, this has been my perspective of working from the bottom. This is the confessions of a QA tester. 

Latest Jobs

Disbelief

Chicago, Illinois
05.10.22
Producer

Build a Rocket Boy Games

Edinburgh, Scotland
05.12.22
Lead Animation Programmer

Windwalk Games

Austin, Texas
05.16.22
Game Designer

Sucker Punch Productions

Bellevue, Washington
05.10.22
Campaign Director
More Jobs   

CONNECT WITH US

Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter

@gamedevdotcom

Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Register
Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Subscribe
Follow us

@gamedevdotcom

Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more