与大多数开发团队一样， Mendix，我们应用 Scrum 来构建我们的应用程序。Scrum 方法的一部分是与用户和利益相关者一起验证产品。然而，尽管许多开发团队尽了最大努力来构建功能性产品，但这一步往往被忽视。通常，人们会把可用性测试复杂化，因此将其排除在开发过程之外，错误地认为它并不重要，或者他们正在节省资源。这是一种遗憾，因为与用户一起测试你的（最低价值的）产品会带来更好的结果。
可用性测试可提高应用程序的成功率
应用程序的成功取决于用户如何使用它。任何可用性问题都会对使用产品的意愿产生负面影响，从而影响应用程序的长期成功。根据《火箭手术变得简单》（Kurt，2010 年）一书，所有应用程序都存在可用性问题，从小问题到严重问题。问题在于，可用性问题通常被设计师、开发团队和产品所有者忽视，因为应用程序应该如何使用对他们来说“太明显了”。
通过可用性测试，可以轻松发现和解释可用性问题。在开发过程中解决这些问题对于创建成功的应用程序至关重要，并且可以避免事后修复这些问题而花费不必要的开发时间和金钱。
人们为什么不进行测试？
尽管与用户和利益相关者一起验证产品是 Scrum 流程的一个重要要素，但由于以下原因，可用性测试常常被忽略：
- 心态：让我们尽快交付应用程序，如果需要的话，我们稍后会进行调整。
- 我们（开发团队）没有遇到任何可用性问题，所以应该没问题。
- 它需要专业知识和知识，而开发团队并不具备这些。
- 而且雇用外部人员来做这件事要花费太多钱。
人们通常认为可用性测试需要几天甚至几周的时间。面对这样的时间安排，大多数人宁愿将资源花在开发新功能上，而不是测试和微调那些对我们来说显而易见的东西。
为您创建的可用性测试方法
了解可用性测试的影响有多大，我们的设计团队建立了一个测试方法 Mendix 我们的制造商可以将其插入到他们的流程中的产品。经过试验，我们想出了一种简单、快速且便宜的方法来测试 Mendix 应用程序。我们设计的方法受到《火箭手术变得简单》（Kurt，2010）一书的启发，为开发人员、设计人员和产品所有者提供了有关如何使用应用程序以及如何改进应用程序的宝贵见解
在此过程中，您总会发现一些您从未想过的有趣事物，解决任何可用性问题都会真正使应用程序更加用户友好。这种方法也是通过邀请利益相关者参与来增加他们参与度的绝佳机会。此外，结果可能表明开发中使用的假设实际上是无效的。
此 Mendix 可用性测试方法
为了简化流程，我们的方法包括三个主要步骤。下面列出了每个步骤以及一些指南，以帮助您充分利用每次测试体验。
准备测试
- 计划 3 个会议 – 提示：使用冲刺评审来进行测试。
- 定义用户场景。
- 在 Mendix 测试环境。
- 进行先导测试。
进行测试
- 观察员应保持静音、关闭摄像头并做笔记。
- 指定一名主持人来指导参与者。
- 要求参与者在执行用户场景时“大声思考”。
- 利用最后 15 分钟向参与者提问，反之亦然。
回顾测试
- 每位观察者提出了他们发现的三个重要的可用性问题。
- 团队共同确定了五大可用性问题。
- 将每个可用性问题转化为新的故事/任务，并将其添加到项目的待办事项中。
为了最好地展示这种方法，让我们以我们为 Hackathon 应用程序* 创建的测试为例。此测试的目标是找出组织者在应用程序中设置 Hackathon 活动时遇到的可用性问题。需要注意的一点是，只花了一个上午就完成了测试。
*注：Hackathon 应用程序允许组织设置和举办完整的在线黑客马拉松活动，黑客可以注册、上传和观看解决方案并查看获奖者。此外，还可以添加陪审团，负责评估解决方案并颁发奖项。Hackathon 应用程序现已推出 车型市场.
设置可用性测试
总共，在项目的倒数第二个冲刺中计划了三个 60 分钟的会议。这使团队能够在发布应用程序之前的最后一个冲刺中解决可用性问题。为了让利益相关者参与验证应用程序，我们要求他们充当参与者或观察员。
准备工作的另一部分是为参与者定义用户场景。团队和产品负责人通过回答以下问题来做到这一点：
- 我们不确定什么事情？
- 该应用程序中最重要的功能是什么？
我们感兴趣的一件事是，组织者如何在应用程序中设置新的黑客马拉松活动。他们是否能够毫无疑虑或障碍地填写表格？他们是否觉得他们可以为新活动添加所有必要的信息？此外，通过创建以下用户场景，与参与者一起测试了在新闻提要页面上为黑客留下帖子的功能：
“为了在黑客马拉松期间支持黑客，您需要发布一系列提示。使用应用程序分享这些提示：
小技巧:
-
- 起身四处走动以保持清醒。
- 打个盹，摆脱困倦。
- 让眼睛休息一下，避免疲劳。“
在写下场景时，我们添加了最少的指导，让参与者自己决定如何完成所有事情。这样做会比规定严格的完成方式更能发掘出有价值的见解。
接下来，该应用程序被添加到 Mendix 平台。为了生成真实的测试环境，添加了其他黑客马拉松活动的虚拟数据，并为参与者创建了用户帐户以进入应用程序。最后，使用试点测试验证了测试设置和环境。
在设置中进行最后的更改后，我们准备开始实际的可用性测试！
进行可用性测试
在每个会议开始时，主持人（这次是设计师，但可以是团队中的任何人）都会解释设置并征求参与者的同意来记录会议，以便团队随后检查。
在整个会议期间，观察员会关闭摄像头并保持静音，以保持参与者和主持人之间的互动。更好的策略是让他们从“另一个房间”观察，以避免让参与者感到有人在看着（甚至评判）他们。
参与者被要求在执行用户场景时大声思考（“大声思考法”）。这让团队比单独观察更深入地了解正在发生的事情。例如，一位参与者没有找到“新黑客马拉松”按钮。多亏他“告诉”我们他认为可以在哪里找到按钮，团队获得了关于如何改进应用程序中最重要按钮位置的宝贵见解。
当参与者演练场景时，主持人只会在需要时为他们提供指导。相信我；当有人陷入困境并必须自己找到出路时，你会得到最有价值的见解。在会议的最后 15 分钟，参与者、主持人和观察员提出的问题都得到了记录和处理。这部分非常适合反思参与者的“痛点”，尤其是在问他们更一般的问题时，例如：“如果应用程序中有一件事你可以改变，那会是什么？”
在这个例子中，所有三位参与者都以相同的方式回答了这个问题：他们将改进“新闻提要”页面的导航。观察者还注意到，找到该页面对他们来说确实很困难。
回顾可用性测试
会议结束后，立即与观察员举行了一次回顾会议，讨论调查结果。会议开始时，每个人都选择并介绍了他们发现的最重要的三个可用性问题。此后，团队共同确定了最重要的五个可用性问题，并将它们从 1（最重要的）到 5（不太重要的）进行排序。根据您发现的重要问题的数量，“前 5 个”可能是“前 7 个”或“前 10 个”，等等。
我们发现的一个关键问题是，在应用程序中添加奖项和奖品的流程不明确。没有一个参与者能够不犯错误地做到这一点。团队从未注意到这是一个潜在的问题，因为对于参与创建应用程序的每个人来说，应该这样做的方式太明显了。
在评审结束时，最关键的问题被转化为新的故事/任务，并添加到项目的待办事项中。由于 Mendix 平台，新的故事/任务很快就被团队处理。所有这些都导致在不到一个冲刺（两周）的时间内应用程序版本得到改进！
结语
可用性测试的重要之处在于，在进行多次成功的测试后，其好处不言而喻。您不仅会生产出更成功的产品，而且参与的团队也会开始将可用性测试视为他们希望参与的开发过程的基本要素，因为他们可以亲眼看到他们的产品是如何使用的以及如何改进。
我希望你能受到鼓励，开始测试你的 Mendix 领域广泛应用，提供了卓越的解决方案。
去做（并测试）它吧！