在游戏中测试复杂的系统

I’ve been testing software for a long time. In fact, my first job was as a tester. In an industry where it evolves faster than what it is possible to keep up with, I wouldn’t consider myself — or anyone as a matter of fact — as a master in software testing, but I have completed the 10, 000 hours of mastery required to qualify me as, at least, competent in the art of software testing.

我已经测试软件很长时间了。 实际上，我的第一份工作是作为测试员。 在一个发展速度跟不上发展速度的行业中，我不会将自己(或事实上的任何人)视为软件测试的专家，但我已经完成了10,000个小时的掌握要求我至少具备软件测试领域的能力。

Over the years I’ve seen testing being more integrated into the developer role with Test Driven Development and I remember the great relief and freedom that exploratory testing brought to the industry. Then there was the introduction of crowd sourced testing which solved the problem of configuration related issues, but it comes at a high cost and doesn’t guarantee issues to be identified.

多年来，我看到测试通过“测试驱动开发”被更多地集成到开发人员角色中，我还记得探索性测试带给业界的极大的轻松和自由。 然后，引入了众包测试，它解决了与配置相关的问题，但是成本高昂，并且不能保证发现问题。

Other than that, the field of software testing has changed very little over the past decade, while the complexity of what we’re testing has increased exponentially.

除此之外，软件测试领域在过去十年中变化很小，而我们所测试的复杂性却呈指数级增长。

一切的简短历史 (A short history of everything)

Testing was easy back when the methods were created. A detailed requirements specification was the baseline from which you drew up a detailed test plan. You then executed each step of the plan meticulously in sequence until completion.

创建方法后，测试很容易进行。 详细的需求规范是您制定详细测试计划的基准。 然后，您将按顺序精心执行计划的每个步骤，直到完成为止。

O, the good old days when things were simple…

哦，美好的过去，事情很简单……

Systems had clear boundaries as integration wasn’t common. It was a safe little black box that you had full control over and a methodical test plan was a very good idea.

系统具有明确的界限，因为集成并不常见。 这是一个安全的小黑匣子，您可以完全控制它，有条不紊的测试计划是一个很好的主意。

There were little to no competition with mostly niche markets paying a premium for automating a part of their value chain specific to their needs. The users’ primary roles were to input data into the system. Catering for multiple use cases for a single function was not common. Rather, the software developers told the users how to use the system. In fact, there was full training courses developed to teach users how to use complicated systems.

几乎没有竞争，大多数利基市场为使价值链中的一部分针对自己的需求自动化而付出了高昂的代价。 用户的主要角色是将数据输入到系统中。 为单个功能提供多个用例并不常见。 相反，软件开发人员告诉用户如何使用该系统。 实际上，已经开发了完整的培训课程来教用户如何使用复杂的系统。

But then came commercial internet, the Google app store and MOOCs which allowed anyone to build any piece of software and make it accessible to the entire world. On top of that open-source became popular and choices became ubandent. You no longer had to pay expensive premiums to use software as there were an abundance of free or lower costed options available.

但是随后出现了商业互联网，谷歌应用商店和MOOC，MOOC使任何人都可以构建任何软件，并使整个世界都可以访问它。 最重要的是，开源变得流行，选择变得无处不在。 您不再需要为使用软件而付出昂贵的费用，因为有大量的免费或成本更低的选择可用。

And then, of course, the shadow side of software emerged with a growing competition to own data with Google and Facebook at the fore-front. Their solution to owning the data was simple — control the log-in point. API’s to handle log-in and as a result access to other user data was introduced and integration became a user expectation. If you wanted to compete you had to integrate to the big players. Which is great for the users and the data gathers on the other side, but terrible for the software developers who no longer had full control over what they were building.

然后，当然，随着越来越多的人争先恐后地要求Google和Facebook拥有数据，软件的影子面出现了。 他们拥有数据的解决方案很简单-控制登录点。 引入了用于处理登录的API，从而引入了对其他用户数据的访问，并且集成成为用户的期望。 如果您想竞争，就必须融入大型企业。 这对用户来说很棒，而数据却在另一侧收集，但对于不再完全控制自己所构建内容的软件开发人员来说，那就糟了。

Testers were suddenly overwhelmed with all the possible permutations to include in any user test and quality eroded despite the longer hours and more fancy tools to automate part of the process.

测试人员突然不知所措，将所有可能的排列包含在任何用户测试中，尽管时间较长且使用了一些花哨的工具来使过程的一部分自动化，但质量却受到侵蚀。

复杂性 (Complicating complexity)

Suddenly, test planning and design had to take into consideration different devices and configurations far beyond anyone’s control. Integrations and personalization further added to the already complex systems making it impossible to use the existing software testing methods to ensure coverage.

突然，测试计划和设计必须考虑到远远超出任何人控制范围的不同设备和配置。 集成和个性化进一步增加了本来已经很复杂的系统，使得无法使用现有的软件测试方法来确保覆盖范围。

Where a decision table to plot the possible test cases were a great tool to ensure coverage, now a decision table is inadequate for even a small step such as onboarding. The number of permutations and variables are simply too many. You have to test self sign-up as persona type one, two and three; self sign-up via invite from persona one, two and three; self sign-up with an existing invite active; sign-up with multiple invites pending from different invitees; sign-up using facebook, google, twitter, email, phone, different types of phones, different browsers, different locations….

决定可能的测试用例的决策表是确保覆盖率的好工具，而现在，决策表甚至不足以完成诸如入职等一小步。 排列和变量的数量太多了。 您必须测试第一，第二和第三角色类型的自我注册； 通过角色一，二和三的邀请进行自我注册； 在现有邀请有效的情况下进行自我注册； 使用来自不同邀请对象的多个邀请进行注册； 使用Facebook，Google，Twitter，电子邮件，电话，不同类型的电话，不同的浏览器，不同的位置进行注册。

You catch my drift.

你抓住我的漂移。

And that’s just sign up. A mere prerequisite to actually using your system.Even if you do have unlimited budget and can afford to add more and more testers, by the time they would finish the planned tests the market place would have shifted so much that your solution would no longer be a fit for what it was designed for.

这就是注册。 只是实际使用系统的前提条件。即使您确实有无限的预算并且有能力增加越来越多的测试人员，但当他们完成计划的测试时，市场将发生巨大变化，以致您的解决方案将不再适合其设计用途。

So what do you do?

所以你会怎么做？

You could scream and pull out your hair while throwing around your weight as test manager demanding more from your already overworked testers. And it might even work for a short while.

当测试经理要求您已经过度劳累的测试人员提出更多要求时，您可能会尖叫并拔出头发，而又会发胖。 它甚至可能会工作一小会儿。

But you don’t use a hammer to fasten a screw and you don’t use a muffin tray to bake a bread. So what if there was a better, easier tool to test complex systems with?

但是，您无需使用锤子来固定螺丝，也无需使用松饼托盘来烤面包。 那么，如果有一个更好，更轻松的工具来测试复杂的系统该怎么办？

“The creation of something new is not accomplished by the intellect but by the play instinct.” — Carl Jung

“创造新事物不是靠智力来完成，而是靠游戏的本能来完成。” —荣格

游戏测试还是游戏测试？ (Playtest or Playful test?)

In gaming the word used for the equivalent of validation or acceptance testing is called “playtesting”. When I first heard that word, I was immediately intrigued. Playtest?

在游戏中，等同于验证或验收测试的单词称为“游戏测试” 。 当我第一次听到这个词时，我立即被它吸引了。 游戏测试？

Being very interested in play mechanics and using play as a tool to engage and motivate teams, I explored a bit more. What I discovered is that it’s nothing other than acceptance testing with the difference being the attitude of the player and the involvement of the developer. It’s effectively blending functional testing and usability testing into a single iteration of test.

我对打法机制非常感兴趣，并把打法作为吸引和激励团队的工具，因此我进行了更多探索。 我发现的是，验收测试不过是玩家的态度和开发人员的参与而已。 它可以将功能测试和可用性测试有效地融合到单个测试迭代中。

Makes sense.

说得通。

However, it lacked the element of play I was so interested in, except for the fact that you were testing a game rather than more serious work. So I invented my own playful test method by adding an element of play onto all the most effective test methods out there — namely exploratory testing, mob testing and of course, usability — or play — testing. After all, if it’s not a good user experience, nothing else really matters.

但是，它缺少我非常感兴趣的游戏元素，只是您正在测试游戏而不是更认真的工作。 因此，我通过在所有最有效的测试方法(即探索性测试，暴民测试，当然还有可用性)或游戏性测试中添加游戏元素，发明了自己的好玩的测试方法。 毕竟，如果这不是良好的用户体验，那么其他任何事情都不重要。

让我们玩 (Let’s play)

上下文和先决条件 (Context and Prerequisites)

Playful test can be used for anything, but is ideal for overly complex and complicated system design. When you have different devices, different personas each with their own dashboards, with a lot of variables and many to many relationships between different users or elements within the system, playful test outshines other methods.

好玩的测试可用于任何事物，但对于过于复杂和复杂的系统设计是理想的选择。 当您拥有不同的设备，不同的角色(每个角色都有自己的仪表板)，系统中不同用户或元素之间具有很多变量以及多对多关系时，好玩的测试胜过其他方法。

For example, a rental agent management app has different functionality and information displayed on interfaces designed for tenants, agents or home owners. Each interface is in effect a separate system, with the user experiencing it as one integrated system. The platform allows each persona to have an optional and many-to-many relationship with a property. A tenant might, for example, be invited to join the system by a rental agent and a landlord at the same time. Or a tenant might sign up themselves and be an active tenant as well as a landlord. A property can be listed by multiple agents and the owner. Once signed up, there is a number of possible actions that can be performed in no specific order. In fact, all most of the rules can be broken in some way. A property can be occupied and available for potential tenants to view at the same time. A rental agreement can be terminated early, even though contractually there is a specified termination date. An agent can manage another agent’s property (or not). The list goes on.

例如，出租代理商管理应用程序在为租户，代理商或房主设计的界面上具有不同的功能和显示的信息。 每个界面实际上是一个单独的系统，用户可以将其作为一个集成系统来体验。 该平台允许每个角色与一个属性建立可选的多对多关系。 例如，租房代理人和房东可以同时邀请租户加入系统。 或者，房客可能会签约并成为活跃的房客以及房东。 一个财产可以由多个代理和所有者列出。 一旦注册，便可以无特定顺序执行许多可能的操作。 实际上，所有大多数规则都可以以某种方式打破。 财产可以被占用，并可供潜在的租户同时查看。 即使合同约定有特定的终止日期，也可以提前终止租赁协议。 一个代理可以(或不能)管理另一个代理的财产。 清单继续。

When the requirements are fuzzy and the variables too many to list on a decision table, it’s time to play.

当需求模糊且变量太多而无法在决策表中列出时，就该发挥作用了。

设置测试 (Setting up the play-test)

Playful test follows the basic rules of testing. Determine a strategy, spend some time planning what and how to test, execute and report. The main difference in test planning is that there are no set sequence as in traditional planning with one test case following the next. Rather, it can be seen as playing with lego where each piece can be used to build something different.

好玩的测试遵循测试的基本规则。 确定策略，花一些时间计划什么，以及如何测试，执行和报告。 测试计划中的主要区别在于，没有像传统计划中那样设置顺序，只有一个测试用例紧随其后。 相反，可以将其视为乐高积木，其中每个作品都可以用来构建不同的东西。

The first step is to create the different building blocks.

第一步是创建不同的构建基块。

第1步-选择个性 (Step 1 — Pick a personality)

On small index cards, write the different persona types adding an adjective to describe the personality. For example the angry tenant, the snobbish agent, the busy landlord.

在小型索引卡片上，写下不同的角色类型，并添加形容词来描述性格。 例如，愤怒的房客，势利的经纪人，忙碌的房东。

Adding an adjective gives more context to a user. It describes how they will interact with the system and what their unique needs will be. An angry tenant might be impatient in getting a response. A snobbish agent might be more pedantic in finding issues when doing an inspection, and a busy landlord might want to bypass parts of the workflow or do an action in a more efficient way than an agent.

添加形容词可为用户提供更多上下文。 它描述了他们将如何与系统交互以及他们的独特需求是什么。 生气的房客可能不耐烦地得到回应。 势利的座席可能在检查时发现问题时比较惯于行事，而忙碌的房东可能想绕过工作流程的各个部分或以比座席更有效的方式执行操作。

The adjective is also the invitation to play.

形容词也是比赛的邀请 。

But that’s all it is.

但是，仅此而已。

An invitation.

邀请函 。

There’s no such thing as forced fun.

没有强迫性乐趣。

It’s up to the participants to accept or reject this invitation freely and without any repercussion. A more playful tester might, for example, immerse himself totally into this role, actively role-playing as a different persona to his usual personality. Another tester might not feel comfortable role-playing and simply act his normal self without any playfulness.

参与者可以自由接受或拒绝此邀请，而不会产生任何反响。 例如，一个更具嬉戏性的测试人员可能会完全沉浸在这个角色中，以与以往不同的性格扮演积极的角色扮演。 另一个测试人员可能不会觉得自己扮演角色很舒服，而只是表现出正常的自我而没有玩味。

Most teams are not ready to be playful if they’re used to a management and control type of environment. To be ready for play there needs to be a strong foundation of trust. To learn more about the prerequisites for play read The Rules of Play.

如果大多数团队已经习惯了管理和控制类型的环境，那么他们并没有准备好发挥作用。 要准备好比赛，必须有一个牢固的信任基础。 要了解有关游戏前提条件的更多信息，请阅读《游戏规则》 。

Create at least two cards more than all the participants to allow each person a choice but will ensure coverage.

比所有参与者多创建至少两张卡片，以允许每个人选择，但要确保覆盖范围。

第2步-定义测试方案的目标 (Step 2 — Define test scenario’s and objectives)

Next, based on the functions within the system, write down test objectives — one per index card — for each scenario as you would in a usability test setting. Be sure to keep the objective cards separate from the persona cards.For example, a tenant might want to search for a new home, or report an issue, or give notice. An agent wants to renew a lease, terminate a lease or do a credit check on a prospective new tenant. A landlord might want to list a new property, sign up a new tenant, or resolve a maintenance request.For a complete user experience evaluation, consider using the Game Thinking framework to help define all scenarios.

接下来，根据系统中的功能，为每个方案写下可用性目标设置中的测试目标(每个索引卡一个)。 确保将目标卡与角色卡分开放置，例如，租户可能要寻找新房，报告问题或发出通知。 代理想要续约，终止租约或对潜在的新租户进行信用检查。 房东可能希望列出新资产，注册新租户或解决维护请求。要进行完整的用户体验评估，请考虑使用“游戏思维”框架来帮助定义所有方案。

Order and group these into small related groups and place them face down. For example, keep all sign-up and login related cases in one pile, all agent cases to list a property in another, cases to sign a lease in yet another, etc.

将它们排序并分成小相关组，并将它们正面朝下放置。 例如，将所有与注册和登录相关的案例放在一堆中，将所有代理案例放在另一个列表中，在另一个案例中签署租约，等等。

These cards will be your main play cards during the play phase with players randomly picking a test objective to perform.

这些卡将成为您在游戏阶段的主要游戏卡，玩家可以随机选择要测试的目标来执行。

Probably the most basic rule of play is the concept of randomness. To create a more playful, and more realistic, test plan, add random events on index cards and shuffle them into the main test object cards. Include an element of fun by adding, for example, a geyser burst, you got a job offer abroad and need to terminate your lease agreement early, or you — as agent — might resign and have to hand over your properties to someone else.

游戏的最基本规则可能是随机性的概念。 要创建更有趣，更现实的测试计划，请在索引卡上添加随机事件，然后将其洗牌到主要的测试对象卡中。 通过添加一个有趣的元素，例如增加间歇泉，您在国外获得工作机会，需要及早终止租赁协议，或者您(作为经纪人)可能会辞职并不得不将您的财产移交给其他人。

第3步-团队设置 (Step 3 — Team setup)

Once you’ve prepared all the different index cards, it’s time to play!

准备好所有不同的索引卡后， 就可以玩了！

Get the team together, consisting of at least the developers, business analysts, designers and testers. Ideally, include a customer proxy and some third party users who has no relationship with the system. Aim for a representative, cross-functional team.

组建团队，至少由开发人员，业务分析师，设计师和测试人员组成。 理想情况下，包括客户代理和一些与系统无关的第三方用户。 旨在建立一个具有代表性的跨职能团队。

Break the group into 3–5 players per group and let each player pick a random role, ensuring each persona is represented per group. For example, each group has to have at least one tenant, while another might have 3 tenants and no landlord, or a landlord and agent etc.

将小组分成3至5个小组，让每个小组成员随机选择一个角色，以确保每个小组代表每个角色。 例如，每个组必须至少有一个租户，而另一个组可能有3个租户，没有房东，也没有房东和代理商等。

Allocate different devices to different players and request them to use different browsers, representative of the test plan. One player might use a Windows laptop using Chrome, another an iPad, yet another a mobile phone with Opera as browser.

将不同的设备分配给不同的播放器，并要求他们使用代表测试计划的不同浏览器。 一个玩家可能会使用Windows笔记本电脑(使用Chrome浏览器)，另一个iPad(iPad)，以及另一部将Opera作为浏览器的手机。

Make sure each device has screen capturing and recording software pre-installed and everyone knows how to use it.

确保每个设备都已预先安装了屏幕捕获和记录软件，并且每个人都知道如何使用它。

步骤4 —播放时间 (Step 4 — Play time)

Once all the logistics are sorted and everyone knows what to do, it’s time to play.

一旦所有的后勤工作都经过分类，每个人都知道该怎么做，就该玩了。

Assign a persona personality card and explain how to play. For larger groups consider splitting the group into players and observers, with the observers responsibility for observing the players as they play and making notes and logging bugs as they occur.

分配一个角色个性卡并解释如何玩。 对于较大的小组，请考虑将小组分为玩家和观察者，观察者负责在玩家玩耍时观察他们的行为，并在出现错误时做笔记和记录错误。

With all the scenario cards face down, let each player pick a card from the top of the pile and complete the test objective, while the scribe (and game master) walks around making notes and observing. Each player attempts to complete their test objective taking annotated screendumps or screen recordings where issues are discovered.

让所有场景卡面朝下，让每个玩家从堆顶挑选一张卡并完成测试目标，同时抄写员(和游戏大师)四处走动以做笔记和观察。 每个玩家都尝试通过发现问题的带注释的屏幕转储或屏幕记录来完成他们的测试目标。

Don’t spend too much time on bug reporting, rather, get just enough information or record the entire session to allow for an uninterrupted play session.

不要在错误报告上花费太多时间，而要获取足够的信息或记录整个会话，以便进行不间断的播放会话。

第5步-回顾和结束 (Step 5 — Retrospective and closure)

Once all the cards are finished, or when there has been sufficient bugs logged, wrap up the test session. In a round-robin fashion, ask for feedback and insights gained during the play.

一旦完成所有卡的安装，或者记录了足够多的错误后，结束测试会话。 以循环方式，要求在播放过程中获得反馈和见解。

Consider adding a target on a whiteboard for players to plot their perspective of system readiness and ask for advice on where they feel attention is needed or what the next steps should be.

考虑在白板上添加一个目标，供玩家绘制他们对系统准备就绪的看法，并就他们认为需要注意的地方或下一步应该采取的步骤征询建议。

游戏规则 (The rules of the game)

The key to a playful experience is to provide enough structure to create an immersive experience while leaving adequate room for exploration and play.

娱乐体验的关键是提供足够的结构以创建沉浸式体验，同时留出足够的探索和娱乐空间。

If your system under test is too complex or complicated to adequately cover with test cases, or if there are simply too many variables to test within limited timeframes, consider adding playful test to your test strategy.

如果您的被测系统太复杂或太复杂而无法充分覆盖测试用例，或者在有限的时间范围内有太多变量要测试，请考虑在测试策略中添加有趣的测试。

Read more about play and playful design or visit www.funficient :

了解更多有关游戏和游戏设计的信息，或访问 www.funficient ：

The rules of play

比赛规则

Design better products with Game Thinking

用游戏思维设计更好的产品

The top 10 ingredients of fun

有趣的十大成分