游戏开拓项目治理：QA需要投入若干人力、时间和金钱？

项目方案是电子游戏开拓项目中最主要也是最困难的一步。

它将通过努力，韶光和金钱去明确游戏的范围和功能。
我将在此分享我和我们团队用于衡量QA须要多少人力，韶光和金钱时所利用的一些窍门和技巧。

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

10%规则

QA/调试开拓规则

我们所利用的紧张内因技巧是“谜题技巧”，即包含：

游戏内容

功能重叠

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

10%规则

10%规则是基于你分配给QA的预算值。
之以是将其称作10%规则是由于大多数中等规模的项目分配给QA测试的钱便霸占开拓预算的10%。
须要记住的是这一打算只是基于开拓者和测试者的用度而并未将美术，音乐，市场营销，法务等考虑在内。
下图便是基本的用度比例；10%是测试本钱，20%是调试开拓（注：基本上便是开拓者去办理问题/调试，或者办理问题/调试所须要花费的韶光，测试者所找出的问题），以及剩下的70%是你的核心开拓团队在游戏中创造并实行技能资产的本钱。

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

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

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

在更大型的项目中，团队和角色常日都拥有明确的划分，即测试者卖力测试而开拓者卖力开拓，常日开拓者的用度都是高于测试者。

以下便是本钱划分指南。
你们或许会抱怨你们的QA本钱划分不同，但是要记住这只是一份指南，如果你所碰着的情形有所不同，那可能是由于你们的开拓团队或者作为独立开拓者的你会亲自实行测试事情而不是将其分配给QA团队。
再或者是受到我所说的“乘数法”的影响，即它将会影响到QA的努力和本钱。

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

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

QA/调试开拓规则

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

贯穿全体项目，之以是会有这一规则是由于测试者用于探求一个问题所须要的韶光与开拓者用于调试同一个问题的韶光一样。

在上面的例子中，我以同样的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）调试开拓团队可能将没有多余可修复的漏洞，以是他们只能回去实行并创造游戏技能资产。

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

以下是体积比例图表：

以是这便是打算QA须要多少资源的基本规则。

下面，我将谈论如何去利用谜题技巧，即针对付如何一步步地准备你的项目方案中的高等QA策略，并打算你的QA过程须要花费多永劫光：

游戏内容

功能重叠

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

这是你的游戏内容和功能打紧张内部分析，将为你的项目供应一份有效的QA本钱打算。

谜题技巧

我将这一方法命名为“谜题技巧”是由于如果要有效运用这一技巧，你就必须将所有游戏功能和内容分解成一些较小的组件然后重新整合它们以呈现出所需内容的紧张部分。
一旦形成，这一谜题便是你的QA策略。
你可以利用该QA策略去实行QA操持并终极利用该QA操持去落实测试案例。

就像上面提到的，它将基于特定顺序将游戏内容，功能重叠和“乘数法”含括在内。
为了更好地进行解释让我们以过于简化的游戏和项目为例。
再一次地，关于例子，初了游辱弄法外你并不须要进行有关繁芜性，性能，第一方发行认证等等测试。
让我们假设其它团队将卖力这些事情。

现在让我们进行深入剖析！

步骤1、游戏内容

首先列出所有游戏内容/功能以及完成100%的内容须要花费多少韶光。
须要把稳的是我建议刚开始不要深入过多细节。
首先你会因此摧残浪费蹂躏大量韶光，其次你该当将更多细节研究留给QA操持和测试案例。

不才面的例子中我们拥有这样一款游戏：

能够在大约5个小时内完成

花2个小时能够看到所有UI功能，包括菜单互动

花10个小时能够网络到所有可行道具

花24个小时能够得到所有造诣

等等。

让我们利用所拥有的信息创造出以下图表：

小贴士：你同时须要把稳我在最下面为毁坏性测试添加了一行。
这并非一个游戏功能。
毁坏性测试是一种没有脚本/探索型测试，常日是面向分外的测试者。
这类型测试者可以利用自己的直觉和聪明才智节制如何在你所预见不到的情形下毁坏游戏。
这些测试者可以看到游戏中的不同功能并轻松地将不同内容组合在一起创造出猜想之外的内容。
对此我并不打算进行更详细的描述，不过我希望你们始终都能为毁坏性测试留出一定的韶光。

步骤2、功能重叠

其次，着眼于你的功能列表并看看测试者可以同时，轻松地覆盖哪些内容。
不才面的例子中，为了完成“造诣”你将须要完成“进程”和“网络”。
它们会重复涌如今3个部分，以是如果你不这么做你将在同样的内容中摧残浪费蹂躏韶光。
关于“音频”，让我们假设所有的其它功能拥有100%的声音和音乐－－我们须要做的只是让测试者将音频作为另一个检讨工具。
不才面的图表中我们已经将总的58个小时所需韶光减少到41个小时。

步骤3、乘数法

末了在你的游戏功能中利用正面和负面乘数法。

正乘数法是指任何能够提高测试者生产率的内容（注：例如游戏中有效的调试或作弊功能，游戏中没有任何大型阻碍成分，供应给QA团队像GDD或参考文件等有帮助的参考资料）。

负乘数法是指任何会降落测试者生产率的内容（例如随机涌现或天生的内容，包括程序天生，或游戏中存在大型阻碍成分，QA团队没有明确的信息或指示，多人游戏检讨须要多人参与等等）。

不才面的例子中让我们假设开拓团队供应了一个基于作弊/调试哀求的架构，将“造诣韶光”减少12个小时，但同时也存在一些随机仇敌以是将增加3个小时去遭遇游戏中的所有仇敌内容。
我们还节省了其余9个小时。
即比起最初的58个小时，我们终极将韶光缩短到了32个小时。

只管作弊/调试功能能够帮助QA进程，但你必须考虑到如果你不肯望在候选版本（RC）中包含这些内容的话你便须要一些测试者在测试过程中不能利用它们，特殊是在靠近RC截止日期时。
紧张是由于作弊和调试功能可能会隐蔽一些主要问题（如掠过一些紧张阻碍成分）或创造出一些本不应该涌如今非调试架构中的内容。

下个步骤

现在你办理了基本的谜题并理解第一个过程须要花费多少韶光。
就像之前所说的，现在你可以利用这些信息去明确你的基本QA策略，创造你的QA测试操持，并为你的测试者供应QA测试案例。
基于游戏，项目或者你们所面对的情形的繁芜性，你须要着眼于其余的一些内容。

下一个步骤便是在你的游戏项目中利用“项目限定模式”。
最广为人知的模式便是三维限定或铁三角，而其最新的更新版本同时也是并不那么有名的模式便是项目管理之星。

关于利用这一模式的一些例子：

明确你的韶光框架和预算，常日是每开拓韶光和预算。

明确你的质量/内容繁芜需求，常日是每游戏内容和你的团队的质量期望值（游戏中有多少内容？我们须要什么类型的测试？我们的质量门槛是什么？我们何时会以为游戏“足够精良”了？）。

确保你能够做到上面两点内容，如果弗成的话你该当尽可能在韶光范围内做出最明智的决定，即关于QA以及你的其它游戏领域你想要花费多少本钱，你想要通报多少内容以及通报若何的内容。
（如果你没有韶光或金钱去测试你的游戏，你可能也没有足够的韶光或金钱去添加音频，创造音乐，创造美术资产，翻译游戏等等，或者你可能想借此去缩减游戏内容/质量）。

明确你须要以及想要进行的QA支持过程（注：例如同等的团队，每个阶段变革的团队或周期性的等等）。

基于你的韶光框架，预算和质量/内容需求以及项目阶段去明确团队规模。

如果是周期性的，明确你须要多少个QA周期以及多久为一轮。

如果是可适用的，明确每个项目周期或阶段的覆盖内容。
（例如音频和UI在beta测试前不可实行且不能进行检测，在alpha测试前每周检测50%的内容，在beta测试时/RC阶段每周检测400%的内容等等）。

更多不同情形都取决于你的项目特性。

以下是我在几年前于一款AAA级游戏中创造的一个谜题/QA策略。
所有的功能和功能类型在左边，然后是所包含的韶光和实行日期，以及每个项目阶段每周的覆盖率，alpha测试前到发行后的实行和DLC的运行等等。
从图表中我们可以看到每个阶段每周所须要的测试韶光，每天所须要的均匀测试者人数，以及该项目所须要的QA韶光和用度。

就像你所看到的，如果你的游戏和开拓方案很繁芜，那么这些事情也就会变得繁芜起来。
但不要担心，我会在之后的文章中进一步谈论这些之后的步骤。
我们将进一步着眼于利益共享者的管理以及QA Pareto观点，即能够帮助你更好地决定游戏的质量标准并根据KPI去决定何时结束QA过程。
希望所有的这些内容能够带给你真正的帮助！

游戏邦编译