Games don’t have to suck and break… so why do they?
There’s a very interesting post up at Game QA Blog that lists possible reasons why games this generation have shipped with problems such as game breaks. Could the reason be lazy developers or is there something even more sinister at hand going on here?
Game QA Blog sets up the story up nicely with Joe B. Gamer’s purchase of the latest Madden game. He puts the game into his console and lo and behold, there are problems. What’s poor Joe B. Gamer to do? He could return his copy of the game, but certainly this is a widespread problem, right?! Right you are, Xboxic reader!
If you’re lucky the publisher and developer will either patch the game or recall it, If you’re not lucky they’ll say this is as it was intended and encourage you to buy the version released next year.
Thankfully most developers are pretty good at getting patches out in a reasonable amount of time… if the patches do anything at all. Oops. Maybe the Prey team could use some QA there.
Who failed you?
Most likely, we’re seeing a combination of failure here. On the part of several testing teams, and possibly a developer. Plus some lower testing standards. I think to some extent all parties involved have lowered their standards, deliberately or not, with the lower quality of their testing teams. Which isn’t to say the testers themselves are entirely to blame. I think it has something to do with how they are treated, how much they are paid, what their expectations are coming into the job, and how long they work at whatever particular testing facility.
This makes sense, but doesn’t really explain the sudden drop in QA for this generation. While games now certainly do take longer to develop and test, things really shouldn’t be that different from last generation, especially considering some of the offerings we’ve gotten haven’t really pushed the 360 to its limits, since we’re so early into the system’s lifespan.
Article author Zachary continues:
This sounds like an exaggeration but it really isn’t that far from the truth. Windows are often covered - when I worked in the northwest United States I would often get to work before the sun rose and leave work without having seen it all day - to prevent glare. Free drinks are provided, and your coworkers are usually friendly.
I know some people will think I’m silly for even mentioning this, though I feel I must. For whatever reason, due to cheapness perhaps, the toilet paper in the facilities is very often the coarsest sandpaper available. I hope this is not indicative of misguided attempts to improve tester efficiency.
I’m still not seeing the issue here. While it does suck working long hours, this article states that other than the toilet paper, the people are friendly and you’re heavily caffeinated while testing. And I don’t think I really needed to see that bit about the TP. Some things are just better left to the imagination.
Ah, I see we’re getting to the root of the problem:
Most beginning game testers are paid around nine to thirteen dollars an hour. I don’t think anyone can properly live off of this kind of pay, especially if they are on-call, especially if they live in the areas around these facilities (expensive burbs), or if they don’t live around them, they have to commute and own a car with the required costs involved. Bussing in to Microsoft each day from Seattle would require waking at 4AM. Naturally if the tester ops for health care (which everyone should, this isn’t a very relaxing job), their pay will be further reduced.
This makes the most amount of sense why some problems are slipping past testers. Working for little to no pay is never any fun (Do you hear that, Curry?
I was kidding! Did you not see the “;)”? Put down the knife!), and if testers are experiencing long commutes then they could just be plain tired after playing the same game all day long. Luckily some of these problems have very easy solutions.
Job expectations and attitude are next in line for why quality assurance has declined.
In reality the testing is fun if you are like me and enjoy making sure that what somebody buys is a finished product. I do not believe all of my past-coworkers have shared this love of bug hunting, and that the end-product may have suffered as a result. Even crap like Sims: Urbz in the City needs good QA. Somebody enjoys the Urbz, for the sake of their happyness, you have to pretend that you like it as well.
So could the real reason for the lack of quality assurance be that the testers just don’t care about games? If they’re making as little as the blog says, there’s probably a good chance that they’re not going to be getting a 360 in their homes anytime soon. Could the lack of QA be sprining from some resentment towards the products they’re testing? This would be a fascinating subject for someone to look into.
After commenting about how game testers can be easily replaced for any reason deemed by management, Zachary sums his point of view up perfectly:
I believe that this policy of replaceable tester units contributes to the lack of quality in many games. If you throw out the accumulated experience of these testers, don’t let them know up-front what to expect, treat them like dirt, and pay them as such, you will have a lower quality product in the end.
As a member of the gaming public, do you feel video game testers should be treated better? Have you ever been a video game tester? If so, what was it like testing video games? How were the conditions at your facility compared to the ones in this article? Do you feel developers should be more strict with their testers just so no bugs are missed?

If you’re lucky the publisher and developer will either patch the game or recall it, If you’re not lucky they’ll say this is as it was intended and encourage you to buy the version released next year.






Ah, a topic close to my heart
I’m a software tester - business apps rather than games - and so I feel a bit of sympathy for the publishers.
You can’t lay the blame at the feet of the developers/coders. They’re only human, they WILL make mistakes, and it is the job of a tester to find them.
I don’t think you can say that QA’ers are lazy because they’re underpaid. If you’re not enjoying your work, you’ll move on to another job, you won’t just do a half-arsed attempt at your current one. Temporary testers are a definite no-no for me though. Often they come without experience (students wanting some extra cash, or who think that they’ll just get to “play” the games), and as you mentioned, you need the accumulated experience of established testers - these will be the people who will recognise quicker when something is deviating from expected behaviour.
Personally I think beta-testing is hugely underrated in games. You get a large base of people who are more than willing to play the game intensively for free, they’ll perform a wider range of actions and report more glitches than your testing team could ever manage. Granted, it’s not so easy for console games, and even if it IS possible, there’s sometimes a bit of a backlash from the common consumer (the Test Drive E3 demo was buggy to say the least, but it was basically a beta and the final product will have improved no end because of this).
Patches are here to stay now - they’ve always existed for PC (again, you can blame us software/application guys for that) but the success of Xbox Live (and whatever the PS3 is bound to offer) means that patches/updates can be delivered seamlessly to the majority of game users. People argue that this just encourages lazy coding/testing, if you know that you can just fix bugs later, but that’s not the case. Peoples jobs are on the line with this sort of thing, and Microsoft’s own certification process would catch any real howlers anyway. What’s the reverse argument? We ban patches? Then when a bug finally sneaks through, you’re stuck with it. I know that’s what it was like in the old days (well, not the REALLY old days - there’s nothing like hacking through a few lines of BASIC/hex code to fix mistakes yourself!), but the situation we have now is far better.
I’ll bet if you paid testers a bonus based on number of bugs found, and docked responsible programmer’s pay accordingly, you’d get some pretty defensive coding and some downright maniac testing going on…
I am obviously kidding….but still…
You’d also have to bankrupt your testers by docking their pay for bugs they missed
Devs and QA have a fairly fragile relationship anyway, QA’s job is basically to break developer’s work, so everyone has to be fairly thick-skinned about it.
I know, I’m a developer ;o) (not games, don’t get excited).
Thing is, I’d say that the responsibility for bugs is shared between programmer/designer and tester. I shouldn’t pass software over to a tester when I’ve not tested everything I think they will.
As a programmer that’s familiar with the code of a project though, it’s very easy to fall into the trap of “positively” testing your code only, which is why external testing is vital.
A coder can still be defensive though…I’ve had amped 3 crash on me recently, and instead of killing my 360, the coder was smart enough to have a catch-all routine that softly resets the game, shows an “oops” animation by way of an apology, and drops you back into the main menu. I’d still rather it didn’t happen, but I’m happier than if I’d had to restart my console.
Is that true about Amped 3? That’s pretty awesome. I’ve only just started playing it, but that’s good to know. It also saves itself fairly regularly, and it’s just a generally brilliant game anyway
I’m working right now as a tester (again not games, just new automated applications at work) And it ain’t an easy job with small numbers (there is only two of us involved in trying to break the application) so we can easily pick out the large bugs, we can get into quite a lot of the more complicated issues but just because of tester numbers and allocated time before the application goes into production we will never pick up every possible scenario.
Which means we try to tackle the main issues that will affect the largest number of users and quite happily accept that there will be errors raised in production which as long as we can identify and fix in an acceptable timescale I don’t see a problem. Which seems to be exactly the same way these guys are working.
Unless you are going to greatly increase the numbers of testers (and maybe the amount of time they have, which would be relative to the amount of testers used) I would have to say this is pretty acceptable, it is just the nature of human error.
My issue is the turnaround times for identifying and fixing errors when they do occur, seems to be an awful long time passes between finding and fixing the problem.