作者：Mathieu Lachance

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

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

10%规则

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过程。希望所有的这些内容能够带给你真正的帮助！

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

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

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 series of entries 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)

In Part1 of this article, we’ve looked at the basic external factor rules we rely on to evaluate how much people, time and money QA should take (The 10% rule & The QA/Debug Dev rule). In this Part 2, we’ll look into the main internal factor technique we use: the “Puzzle technique”.

And, again, 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 Puzzle Technique

I’ve named this method “Puzzle technique” because to apply it properly, you have to cut out all of a game’s features and content into smaller and smaller pieces and then reconstruct all of them to provide you with a big picture of the required work. That puzzle, once built, will be your QA Strategy. You can then use that QA Strategy to feed your QA plan and then, finally, use that QA plan to feed your testcases.

As mentioned before, it considers the game content, features overlaps and multipliers, in that specific order. Let’s take the example of an oversimplified game and project for the sake of the process explanation. And again, for the sake of the example, you do not need to do any Compatibility, Performance, First Party Publishing Certification, or any other type of testing than Gameplay. Let’s assume another team will cover the other parts (If you want me to cover strategy and execution of some of these other features, we’ll do it in other posts.).

Let’s delve in!

Step 1: Game content

First, list all of the game’s content/features and how much time it would be necessary for a normal user to see 100% of that content. Note here: I’d suggest to not go too much into details for the first pass. Firstly because you’ll spend too much time and overthink it for nothing, and secondly because going into details should be saved for your QA Plan and then testcases.

In the below example, we have a game that:

Can be completed in about 5h

Takes about 2h to see all UI functionalities, including menu interactions

Takes about 10h to collect all available items

Takes 24h to complete all achievements

Etc…

Let’s populate the below table with the information we have as of yet:

1Free tip: You’ll also notice that I added an extra line at the bottom for destructive testing. It’s not a game feature. Destructive testing is a type of unscripted/exploratory testing which is usually reserved for a very special type of tester. The type of tester that is able to use his gut, instinct and smarts to know and feel how to break the game, outside of your plan and testcases. The type of tester that sees different features in a game and can easily put 1 and 1 together to make something unexpected happen. I won’t go too much in details here as I could have an entry solely for scripted vs exploratory (including destructive) testing, but always, ALWAYS, reserve some time for destructive testing.

Step 2: Feature overlaps

Secondly, look into your list of features and see what can be covered simultaneously, easily and naturally by a tester. In the below example, to complete “Achievements”, you’ll need to complete “Progression” and “Collectibles” naturally, so we can reduce those to 0%. They have repeat coverage in all 3 sections, so if you don’t do so you’ll be wasting time on the same content coverage. Regarding “Audio”, let’s assume that looking into all other features will allow to hear 100% of sounds and music – all we need to do is to instruct testers to bug audio as discovered2. Per the table below, we’ve already reduced the required total time for a full pass from 58h to 41h.

Step 3: Multipliers

Finally, apply positive and negative multipliers to your game features.

Positive multipliers are anything that increases the productivity of the testers (e.g. efficient debug or cheat features within the game, no major blockers within the game, effective and useful reference material given to the QA team like the GDD and/or walkthrough docs, etc.).

Negative multipliers are anything that decreases the productivity of the testers (e.g. random appearance or generation of content – including procedural generation, presence of major blockers within the game, no/unclear/contradicting information or instructions given to QA team, Multiplayer checks requiring multiple people, etc.).

In the below example, let’s say the dev team provided a build with cheat/debug commands that allows for easy progression, reducing “Achievements” time by 12h3, but there’s also some random enemy encounters that adds about 3h to see all enemy content in the game. We saved another 9h. 32h total instead of our original 58h.

3Even though Cheat/Debug features usually helps QA progression, please take in consideration that you may want to take them out at some point if you don’t plan to publish with them included in your Release Candidate (RC) build, and you may also want some testers to not use them while testing throughout all the time, especially when nearing RC. The main reason being that active Cheat and Debug features may hide some important issues (e.g.: jumping over major blocker) or make new ones appear that wouldn’t be present in a non-debug build, which wouldn’t require any fix (thus wasting your testers’ and developers’ time).

Next steps

You now have your base puzzle done and know how much time is needed for 1 full pass. As shown previously, you can now use that information to present your base QA Strategy, build your QA Test Plan, and from that build your necessary QA Test Cases for your testers. Depending on the complexity of your game, project or even situation you’re in, you may need to look into a few other things.

The next steps, if applicable, are to apply the “Project Constraint Model” to your game project. The most well-known model of it being the Triple Constraint or Eternal/Iron Triangle, and its newest/updated and lesser-known counter-part, the Project Management Star.

Some examples of that application:

Defining your timeframe and budget, usually per your development timeframe and budget (see Part1 of this post).

Defining your quality/content coverage requirements, usually per your game content plan and your team’s quality expectations (How much content is there in our game? What type of testing do we need? What’s our quality threshold? When should we consider the game “good enough”?).

Make sure the two above points are aligned, and if not, making as much of an informed decision as you can regarding your timeframe, how much you want to spend, the amount of content you’ll deliver and the quality of the content you’ll deliver, for QA but also all other spheres of your game (if you don’t have money nor time to test your game, you might not have enough time or money to also develop, add in audio, create music, create art assets, translate your game, etc… and/or you may want to scale back on content/quality).

Defining the QA support coverage process you need and want to apply (E.G.: constant team, fluctuating team per phase, cyclical rounds, etc.).

Defining your team size based on your timeframe, budget and quality/content coverage requirements and project phase.

If cyclical, defining how many rounds of QA you’d need and when.
If applicable, defining the coverage requirements per project rounds or phase. (E.G.: Audio and UI not implemented and can’t be checked before Beta, Checking 50% of content per week in Pre-Alpha vs. Checking 400% of content per week in Beta/RC, etc.)

And more depending on your project’s specificities.

Below’s a partly censored Puzzle / QA Strategy I had built a few years ago on a AAA title. All features and feature types on the left, then coverage times and implementation dates, and then % ratio of coverage per week per project phase, from Pre-Alpha to Post Release support and into DLC work. From there, we could know the amount of necessary tester-days per week per phase, and thus average amount of testers per day and the exact amount of QA, time and money necessary for the project.

As you can see above, if your game and your development plan is complex, the work for this will get complex as well. Don’t worry, I will cover some of these Next Steps in future entries. In my next post we’ll look at stakeholder management as well as the QA Pareto concept, which helps you decide the quality level of your game as well as when to close a QA project based on pre-defined KPIs. I hope you enjoyed the post and found it useful! And, as always, feel free to leave any comments and questions and I’ll try to answer as best I can.

Also, 2 BIG NEWS for those courageous enough to have read through the whole article!

News #1: For those interested in meeting me and some of my colleagues next week, we will be in Barcelona, Spain for the Game QA & Localisation Europe 2016 Conference from June 28th to 30th AND we have 5 free client passes to give out. Message me rapidly if you’re interested in getting one of these passes!

News #2: My colleagues , Nicolas Liorzou & Stefan Henry-Biskup, will be speaking about Tips & Tricks on shipping a world class indie game: the Publishing-as-a-Service option and Finding “the Awesome” All Day Long at Mexico’s Campus Party next week also. If you have the chance, I’d highly suggest dropping by to see their presentation!

Until next time!（source：gamasutra）