Hey guys, could any professional game tester tell me how your daily job is like? Is it fun? Is it way too booring to play and replay games all day long? How does the salary look like? How lower than a programer’s salary is it?
Also, one of the most important questions, how would you start at this area?
Thank you in advance,
Rafael
QA is a highly skilled job when done properly. When we get proper QA done it includes tips for adhering to guidelines, the process for repeating a bug, screenshots and so on. You are going to be under-appreciated, overworked and ordered to play the same section over and over and over again on a minimum wage salary.
It can be very boring.
I have the greatest of respect for quality QA and feel they do make a massive difference to a title’s quality. The problem is the QA staff don’t feel that way due to how under appreciated and underpaid they are.
This idea you sit around playing games is stupid. It’s a proper job not something you can just have fun with. You’ll get fired if you don’t get results. But I’m talking about proper QA, not your concept of it.
I only know this because I’ve had proper QA on one of my games and a good friend is a QA tester.
In order, as someone who did it for 8 months (but no longer):
Monotonous, aggravating and unfulfilling.
No.
You don’t “play games all day”. You play half-finished bug-ridden monstrosities. You don’t play the game itself, you play tiny chunks for entire hours or days to replicate bugs.
Salary is at or near minimum wage, which is considerably lower than a programmer.
With that said, if it’s in-house (meaning you work in the studio) there is potential for moving into a development role if you can get your work in front of the right people (and assuming your work is up to par). Otherwise, you can still go the QA/Production route. Q/A, once you move out of the entry-level world, can lead to more rewarding jobs.
EDIT: In response, to hippocoder-- I don’t meant so sound like QA is not super-important, I agree with him, it’s an extremely important chunk of the team, and can have a huge impact on the final product. My response was meant to set expectations regarding a choice of career in that world. In other words, don’t get into QA to do QA forever.
Lets be a bit realistic. There’s no career path from QA beyond QA manager. It simply is rarer than hen’s teeth that ever happens. I’m not sure why people perpetuate that. QA is high turnover, people join, burn out, leave. And they leave angry because they expected they’d have a valid role in game development due to people saying they can move up. Maybe it does happen. But I’m 100% sure it’s incredibly rare.
If it does happen, it will be because your skills are ideal for the opening and you’d still be judged on the same merits as a newly-applying programmer or artist. QA is an important job in my eyes but I wouldn’t presume to encourage people to think of it as a gateway job.
Indeed, it’s rare to move into a development role from QA, but even for the large (VERY LARGE) company I worked for, it was possible.
In addition, QA, more often than you may realize, leads into more producer-esque roles within the organization because of skill set.
I remember reading a post by a real game tester for a AAA studio and in the short term it is fun, but in the long run it stops.
An example was a 3D game where the tester spent many hours simply plummeting to his/her character death on screen just to verify that they correctly fell to the toon’s death whenever they stepped off the cliffs in the game zone they were in. So it was literal load game-die-reload game-die-reload game-die; for many hours, than test same scenario but involving being attacked by enemies. If the enemy hit you near a cliff would you correctly be knocked off the cliff?
So now it was spawn enemy than let enemy hit you and see if you fall off the cliffs. reload game-enemy hits you-you die-reload game, and you had to do that on every cliff section in the entire zone. If there were many cliffs your whole week would be validating this process non-stop for 8 hours a day 5 days a week.
From what he/she wrote about was, some testing can be fun, some can be immensely fun, but usually the easy test stuff doesn’t last long and could be the funniest part of all, then the tedious crap takes over and it is what takes the longest amount of time and also is not fun in the long run.
However it is an easy way to get your foot in the door in video game development. If you also have a good background in programmer or even a simple Associate or a BA in programmer (especially in C++) it could be the beginning of a programming career, but there is still no guarantee.
I’m working as QA Engineer in Unity for about 4 years now and it’s hard but awesome job. I’m happy everyday to be able to improve Unity quality. 
On another hand, QA in games is a lot different than QA of engine, since it requires completely different set of skills.
Also, QA is not that different as being a programmer though, we just usually write code for different purposes.
“QA is like sex, if you are not having a good time, you are doing something wrong.” - James Bach
You should check out Steam paid early access alphas, littering greenlight. You get to pay for the privilege of doing what you just described
Yeah it’s of a tom soyer where they pay you to help bug test
A couple of good blog posts on the subject of quality QA testing:
Coding Horror: Making Developers Cry Since 1995
DId I Remember To (Michael Hunter)
You Are Not Done Yet (PDF, Michael Hunter)
Testing a game over and over again for bugs is really boring.
But making the games and testing them afterwards is really awesome!
I recommend you to find what you are good at.
If you’re going to be a indie dev then you should let the public test your games or test them yourself.
-GamehubDev
Don’t do it lol 
And now I see why 4.3 is taking so long… :shock:
QA is cool and all but IMO it isn’t worth the time, may as well try and develop your own games than be cheap labour!
My first job in IT was as a manual software tester. While this was not in a games company, the simple fact remains that games are software. So, some advice may be helpful.
As a software tester you’ll find yourself doing two things - writing test cases to figure out how to test some aspect of the package you are testing, and actually performing the tests to see if they produce the results you are seeking. In a sense, it’s like being a programmer…except that you’re the adversary, and usually work in slightly more hostile conditions than a developer would, because you’re the guy trying to find what everyone else did wrong.
At the job I worked, we used very diplomatic language to get around this, when pointing out problems (which, we did fairly often.) Instead of [Insert Product Name Here], we would refer to the system under test as…well, either the ‘system under test’, or ‘the Application.’
We would have to double check our findings with Business Analysts - people who documented the rules our system was supposed to follow - to ensure our discoveries were legitimate (much of the time they were, but you’d be suprised how easy it is to find a ‘bug’ that’s in there on purpose.) Because that was a weird hybrid waterfall-agile place (among other idiosyncracies) they had that position; as a tester in a more modern, Agile-based world, you probably won’t even have that.
That’s where you get to documenting your findings. We often had to store:
-A description of the problem
-The hardware configuration it was encountered on
-The software configuration under test (we had three for this system)
-The steps to reproduce
-The expected result (in other words, the correct behavior we wanted to see)
-The unexpected outcome (in other words, the symptoms that we didn’t want to see)
…In the course of a normal testing event, which in true waterfall fashion would come at various places in the process and usually take two to five days due to the scope of the application. These would usually be found while validating tickets in the current changeset, or regressively testing more critical tickets.
In short? It’s a long, tedious, thankless job that requires as much discipline as a developer. That being said, it’s absolutely critical, and if you can find a place with processes in place to make it bearable, you may have an enjoyable job.
Unfortunately, those are somewhat rarer than observable Higgs bosons.
Thanks for all the response!
Well, I was rather just curious about it, I already saw that I had skills and plesure with programing, but still, it would be awsome to not have those certain times where you have no idea where the error in your code is, and after 2 hours of searching and googling, you find out it’s a “;” that was missing… Programming is fun and addicting, I just wisht I knew more about it haha.
Thanks guys, I’d say QA is not really what I’m after since I get angry pretty fast when having to re-do things.
Rafael.
This backs up what I’ve heard from others who did the same thing. It’s not even much of a “game” that you’re messing around with most of the time because it’s unfinished and probably broken. And even when the game is getting towards done, you’re not playing, you’re testing, so it’s highly directed and not much fun and very monotonous.
An approximate quote from an ex game tester: “Yeah, I was a tester on [a late 1990s racing game] and my job for a few weeks was to drive around each track and hit each obstacle and wall from a bunch of different directions a bunch of times each at a variety of speeds.” And of course whenever something unexpected happened he had to write a bug report, and then test it again after the level builder thought they’d fixed it. For some types of testing you’d also have to repeat the failed test a bunch of times to see under what precise circumstances it fails to include in the report.
Well, you’ll get past the “missing semi-colon” errors pretty quickly with some practise. Within probably a few months you’ll be at the point where a statement with a missing semi-colon will practically jump out and slap you in the face when you as much as glance at the screen.
Programming is pretty much a combination of a) solving new problems and b) cranking out code for an already understood and well documented solution. The former is where the fun is at, because that’s where you get to be creative and really own your solution, but the latter is where people start because early on there’s a lot of really useful learning to be done there (ie: see and understand how common problems have been solved well, so that you can apply it to your own work, but also adapting the solutions to fit your needs - if they didn’t need some level of adaptation then you wouldn’t need to re-write them). Learning to solve new problems for yourself is not only where the fun is, but it’s also what sets apart a good programmer from copy-paste coder (ie: someone who can only do b - they can write code but they can’t do the problem solving).
Well, QA can be a boring and stressful job, but I think you can make some connections there and if it is your first job, theres some room to improve. I know someone who began its carreer as a QA person, and then learned 3d graphics, and later joined to that team as a 3d artist. Not very common though, most testers don’t do that.
At us, a good tester was always someone who didn’t just tested the game, but moved the whole case forwards, always tracking that his reported bugs are in what state, and personally told the responsible programmers and the artists about that bug, urging them to fix it very soon Basically communicated&managed the bug fixing part too. It was very annoying sometimes, but definitely helped the project.
Rather hold out for a junior programmer job.
Build a Unity programming portfolio, and get interviews/work based on that.
Remember, each year spent doing QA, is one less year experience in being a programmer.
And programmers make more money, and their job is a lot more fulfilling and creative.