I do not work in the industry and I wondered very broadly what percentage is given over to play testing versus getting the bugs out. Or does no-one really work it like this?

  • 1
    \$\begingroup\$ One could argue that play testing is testing the code. I don't think there's any standard split between the two. Though in my own testing, I do far more mini-play tests than I do unit tests or pure code tests. \$\endgroup\$
    – House
    Commented Oct 15, 2012 at 14:54
  • \$\begingroup\$ You test what gives you problems, what you are unsure of, or what you are currently upgrading. \$\endgroup\$ Commented Oct 15, 2012 at 15:02
  • 2
    \$\begingroup\$ Think of play testing as broad scope, and code testing as narrow scope. When play testing reveals something that needs to be worked on, you switch over to the code and see what's going on. \$\endgroup\$ Commented Oct 15, 2012 at 15:05

2 Answers 2


Those are quite different things and it's hard to give a definite percentage.

QA (≈ hunting bugs) is usually the job of a entire QA department, this can include several employees, and even several companies or locations. This is a day-to-day task: the earlier bugs get spotted, the earlier they get fixed, so the bug hunt is really running continuously. Usually this task is taking more and more space when production advances, from almost nothing in pre-prod to almost 100% when getting close to a gold master. E.g. at the end of a production, big studios take advantage of time zones to get daily builds tested overnight, literally from the other side of the world.

Playtesting on the other hand is something that's performed less often, but requires more preparation. For it to be useful, you need to find and select playtesters, you'll want them to match your target audience, and you'll have to prepare playtesting sessions to get the most useful information out of it. "Digesting" what gets out also takes some time. Because of those requirements, this is something performed occasionally, but regularly anyway (I'd say from two week to two months for a big studio). But that's for formal playtesting, everybody involved in making a game actually gives input on it on a daily basis: that's not something really measurable.

  • \$\begingroup\$ Thanks, I am surprised that with so much money going into games that there is not a more considered play testing is not ingrained, especially where studios are attempting to attract game players that are not the type to be employed in game studios! Thanks for the answer, this one just pips Christian. \$\endgroup\$
    – Phelan
    Commented Oct 16, 2012 at 8:36

I don't think you can say "you need X percent play testing and Y percent bug testing", because there can't be a general formula for that. Maybe you're lucky and get the game mechanic right at the first or second try, or maybe you have to iterate a lot and end up going through dozens and dozens of playtest sessions.

Similar situations might be true for bug hunting sessions. Maybe your code is very clean and bug free to start with, or maybe you manage to hunt down most bugs in one or two sessions, or maybe you have bad luck and each time you fix one bug, another one emerges and it draws on and on.

Then there's the point that while you're playtesting, you might find some bugs as well, and when you're hunting for bugs you might notice some gameplay problems. So you can't even clearly separate the two.

It all really depends on the type of game you're making, the game itself, your ability and experience and maybe even a lucky choice of initial values for a lot of things.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .