作者：Mathieu Lachance

项目规划是电子游戏开发项目中最重要也是最困难的一步。它将通过努力，时间和金钱去明确游戏的范围和功能。我将在此分享我和我们团队用于衡量QA需要多少人力，时间和金钱时所使用的一些窍门和技巧。

我们所依赖的最基本的外因规则是：

10%规则

QA/调试开发规则

我们所使用的主要内因技巧是“谜题技巧”，即包含：

游戏内容

功能重叠

“乘数法”（即正面和负面的QA项目/比例影响元素）

今天我将首先讨论两个外因规则。开始前我想先申明这一方法适用于所有电子游戏的QA！

10%规则

10%规则是基于你分配给QA的预算值。之所以将其称作10%规则是因为大多数中等规模的项目分配给QA测试的钱便占据开发预算的10%。需要记住的是这一计算只是基于开发者和测试者的费用而并未将美术，音乐，市场营销，法务等考虑在内。下图便是基本的费用比例；10%是测试成本，20%是调试开发（游戏邦注：基本上就是开发者去解决问题/调试，或者解决问题/调试所需要花费的时间，测试者所找出的问题），以及剩下的70%是你的核心开发团队在游戏中创造并执行技术资产的成本。

development budget（from gamasutra）

从根本上来看，如果一个项目越大，那么QA成本在总成本中的比例就会越低。原因如下：

当QA团队可以同时看到多种资产和功能时，即在较大型的项目中所拥有的条件，他们的生产力便会显著提高。

在长期发展的项目中，QA领导者将分配给测试者特定功能，让他们会随着时间的发展而变成专家并获得更多生产力。

在更大型的项目中，团队和角色通常都拥有明确的划分，即测试者负责测试而开发者负责开发，通常开发者的费用都是高于测试者。

以下便是成本划分指南。你们或许会抱怨你们的QA成本划分不同，但是要记住这只是一份指南，如果你所遇到的情况有所不同，那可能是因为你们的开发团队或者作为独立开发者的你会亲自执行测试工作而不是将其分配给QA团队。再或者是受到我所说的“乘数法”的影响，即它将会影响到QA的努力和成本（我将在另一篇文章进行具体说明）。

ration of development staff（from gamasutra）

以下是来自一个开发者的例子。他的游戏花费了57.1万美元，其中QA便占据了将近20%的成本。

cost（from gamasutra）

如果我们只是计算27.8万美元的开发预算（即开发和QA成本），那么测试成本便占22.3%，这便非常接近我们的预期。

cost（from gamasutra）

QA/调试开发规则

10%规则是基于支出，而QA/调试开发规则则是基于测试时所需要的人员数量。从根本上来看，你分配给项目的测试人员数量不能超过同一个项目中修改/调试漏洞的开发者的数量。除非是在测试开始后，即测试者开始理解你的游戏，并找到所有显著问题，以及当项目即将完结，游戏质量显著提高且测试者所找到的漏洞数量急剧变少时。这两中情况都是测试团队在项目一开始规模很小并在最后壮大的原因。

贯穿整个项目，之所以会有这一规则是因为测试者用于寻找一个问题所需要的时间与开发者用于调试同一个问题的时间一样。

development staff ratio（from gamasutra）

在上面的例子中，我以同样的3个核心角色和10%QA团队成本为例。之所以是以18%的员工比例而不是之前说的10%是因为开发者的成本通常都是测试者的2倍。

你可以看到，测试者和开发者解决/调试问题的努力或容积值是相平衡的。在大多数项目中你总是希望能够创造这种平衡。如果失去了这种平衡，便会出现下面两种情况中的一种：

1.如果寻找漏洞的测试者人数超过解决漏洞的开发者人数：

1）QA团队将找到所有/大多数可找到的问题。

2）调试开发团队将不能在QA过程种解决所有/大多数所汇报的问题，如此便会累积更多问题并远超过调试开发团队的力所能及范围。

3）如果漏洞不能快速得到解决，QA团队的效能将逐渐下降，甚至会完全停止下来，如此便会浪费大量的时间和金钱。

我在几年前便曾遇到过这样的情况。一个大型发行商想和我们合作一个项目，他们中有2个人创建了一个非常出色的原型，所以该发行商想进一步去支持这一项目。在了解了他们的时间安排为6个月并且游戏大量的功能后，我们认为该项目大约需要5名测试者和2名开发者。但是在QA开始后3周，测试者仍然无事可做，所以我们建议停止QA直至开发团队修改了所有汇报过的问题并补充一些额外内容。我并不想在此细谈这件事，只是想说这个游戏项目最终花了超过2年的时间，远远长于最初计划的6个月！

2.如果解决漏洞的开发者人数超过寻找漏洞的测试者人数：

1）QA团队将发挥100%潜能，因为在整个过程中将能够解决大多数找到的问题。

2）调试开发团队可能将没有多余可修复的漏洞，所以他们只能回去执行并创造游戏技术资产。

显然，如果你的开发团队的角色分配足够灵活，如果你的项目分配了足够多的测试者，那么第二种情况明显比第一种情况好多了。这也说明了当项目中没有漏洞可以进行修复时，你们可以相应地调整开发团队的角色。

以下是体积比例图表：

ration of development staff（from gamasutra）

所以这便是计算QA需要多少资源的基本规则。在我的下一篇文章中我将讨论如何去使用谜题技巧，即针对于如何一步步地准备你的项目规划中的高级QA策略，并计算你的QA过程需要花费多长时间：

游戏内容

功能重叠

“乘数法”（即正面和负面的QA项目/比例影响元素）

这是你的游戏内容和功能打主要内部分析，将为你的项目提供一份有效的QA成本计算。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

How much people, time and money should QA take? Part1

by Mathieu Lachance

Project planning is one of the most crucial and difficult steps of a videogame development project. It sets the scope of the game and its features and, through those, the amount of effort, time and money that is planned for it. With this entry I’ll share a couple tips and techniques my team and myself use to calculate how much people, time and money QA should take.

The most basic external factor rules we rely on are:

The 10% rule &
The QA/Debug Dev rule

The main internal factor technique we use is the “Puzzle technique” which considers:

Game content
Feature overlaps &
“Multipliers” (Positive and negative QA project/ratio influencers)

I’ll discuss the Puzzle technique in a future entry; this one will cover the two external factor rules mentioned above. And before I start and get the question: “Matt! Does this apply to Dev QA or Publisher QA? Or outsourcers?”, this applies to all videogame QA!

The 10% rule

The 10% rule is based on the budget value that you assign to QA. It’s called as such because for most mid-sized projects, approximately 10% of the development budget would be assigned to QA testing. Bear in mind that this calculation should only be based on developer and tester expenses. It doesn’t take in consideration Art, Music & SFX, Marketing, Legal, etc., but solely what can be considered development or “engineering” expenses. Below is an example of what it would look like typically in terms of expenses; 10% of costs to testing, 20% to Debug Devs (essentially your developers fixing/debugging, or the amount of time spent fixing/debugging, the issues found by the testers) and the rest, 70%, to your core development team creating and implementing technical assets in your game.

As a general rule, the bigger the project, the less QA should cost in terms of total proportion. This can be explained by a few things:

QA team productivity is increased when they can see multiple assets and features simultaneously which is normally the case for bigger projects.

For longer projects, QA Leads will often assign testers to specific features, making them experts and which will gain productivity over time.

For bigger projects, teams and roles are usually more well-defined – testers test, and devs develop, and developers are usually a bit more expensive than testers.

Below is a guideline for that cost. As you can see, the concepts explained above can be clearly identified. I can already hear some of you complain that your QA cost experiences differed. Remember, this is a guideline, and if you see a drastic difference, there might be a few points you didn’t take in consideration. One may be that your dev team, or yourself if you are an indie, have been doing that testing instead of an assigned QA team. Another big influencer might be what I call “multipliers”, factors that can impact QA efforts and costs drastically (we’ll have a look at multipliers in my next entry).

Here’s an example from a developer that was kind enough to share information. His game cost him 571K$. So, based on the above cost you’d expect QA to be close to 20% (between Indie/B game and A type).

If we solely take the development budget of 278K$ (Dev and QA costs), we get 22.3% for testing, which is indeed very close to what we were expecting.

The QA/Debug Dev rule

While the 10% rule is based on expenditures, the QA/Debug Dev rule is based on average staff volumes while testing occurs. Essentially, on average, the amount of testers you assign to your project should not exceed the amount of developers assigned to fixing/debugging bugs on that same project. The biggest exceptions to this rule can sometimes be right after the beginning of testing, when testers are starting to understand your game, get productive and find all of the most obvious issues, and when nearing the end of your project, when quality is already quite high and the amount of bugs found per tester drops drastically. Both of these usually even out as an average and are partly why test teams are quite small at a beginning of a project and a lot bigger near the end.

The reason behind this rule is, on average across a whole project, the average amount of time it takes for a tester to find and regress an issue is about the same as the amount of time it takes a developer to debug that same issue.

In the example above, I’ve taken the same 3 core roles and the same “10% cost QA team” example (mid-sized AA project). The reason why the above is showing an 18% staff ratio rather than 10% as before is because a Dev usually costs about twice what a tester would.

As you can see, the effort or volume value between testers and the developers fixing/debugging the issues found is balanced. You will want to maintain a relative balance for most of the project. If you don’t, one of two things could occur:

1.If you have more testers finding bugs than developers fixing them:

a.The QA team will find all/most findable issues.

b.The Debug Dev team will be unable to fix all/most reported issues between QA rounds, and the backlog of issues will go up drastically, more than what the Debug Dev team can handle.

c.The QA team’s efficiency will gradually go down, and even potentially go to a stop, if bugs are not fixed rapidly enough, thus wasting time and money.

A good example of the above is something that happened to me a few years back. A big publisher approached us with a project; 2 guys in their basement built a great prototype and the publisher decided to back it up. After reviewing their timeline of 6 months and the game’s high amount of features, we evaluated that the project would need about 5 testers to get everything checked and fixed. 5 testers, 2 developers… After 3 weeks of starting QA, the testers had nothing to do and we suggested to stop QA until the development team could fix most of the issues reported and add in additional content. I won’t go into all of the details but, unsurprisingly, the game project was completed after more than 2 years. A lot further away than the initial requested 6 months!

2.If you have more developers fixing/debugging bugs than testers finding them:

a.The QA team will likely work close to 100% of their potential, because most of the found issues could be fixed between rounds.
b.The Debug Dev team might have no bugs left to fix very rapidly, but can then move back to implementing and creating technical assets for the game.
Obviously, the second situation is a lot better than the first IF your development team is flexible regarding roles and IF you’ve actually assigned enough testers to your project. It also proves the proposed balance by forcing it on you naturally, when no bugs are left to fix, by adapting the role of your development team.

For the curious types, here’s what the volume ratio graph would look like:

So, that’s it for the basic rules to calculate how many resources QA should take. In my next entry, I’ll show you how to use the Puzzle technique, more specifically how to prepare the high-level QA strategy part of your project plan, step by step, and calculate how long your QA rounds should be based on:

Game content

Feature overlaps &

“Multipliers” (Positive and negative QA project/ratio influencers)

It’s the main internal concrete analysis of your game’s content and features which provides a concrete QA cost calculation to your project. Be there!(source:gamasutra)