制定可用性测试计划(一)

测试前改动的产品有可能无法正常使用。

下文列出了为何需要制定详实计划的原因，以及在开发团队中测试计划作为沟通工具的使用方法。

作为测试的计划准则

正如图纸精确画出了所要建造的房子一样，测试计划也精确描述了将如何去测试你的产品。你肯定不愿意建筑承包商在建造房屋时不按计划地即兴发挥，可用性测试同样遵循这一逻辑。测试计划确保一切有据可循。在测试第一位被试时，你肯定不希望测试中仍存在尚不清楚的事项。

作为主要沟通工具

测试计划是设计师、开发者、测试主持人以及团队其他成员的主要沟通工具。开发团队和管理团队(如果他们感兴趣且在团队中)的相关人员应该仔细阅读测试计划的文档报告：了解测试是如何进

行的，并确认是否已满足他们的具体需求。你可以利用计划从其他成员那儿获得建议和反馈，以保证每个人都同意将要进行的实战测试。进行的项目每天每周都会有变化，你也不想在测试结束后某人质疑他或她的某些需求没在测试里出现。另外，如果这是你组织的第一次测试，更要让测试结果的相关负责人员审查测试计划。这也保证了计划的商业性和政治性。

计划写明或暗含所需资源

测试计划描述或暗示了测试所需要的内部和外部资源。一旦你准确列出了何时将进行何事，那预估测试所需的资源这一任务就变得清晰容易了。无论是直接写明亦或是间接暗示，测试计划包含了成功测试所必需的资源。

计划是测试和实际阶段的连接点

没有测试计划，细节就会变得模糊不清，尤其是在截止时间的压力下。测试计划迫使你的测试方法具有系统性，提醒开发团队即将到来的截止日期。说了这么多，这是完全可以接受的，并且是极有可能发生的。当你逐渐了解更多的测试目标，与参与测试的被试沟通更多时，测试计划在这个阶段中也会逐渐优化。项目是动态的，当测试真正开始时，即便是看起来最完美的计划也不得不变更。通过优化测试计划，你可以适应过程中遇到的变数。例如，当你的时间和资源的限制越来越清晰的时候，你可能变得不那么雄心勃勃了，而是想敷衍了事。或者，也许你没有按照自己的设想找到足够多合格的参与者。也许不是文档中所有模块或章节的需求都将按时准备好。也许你的测试目标太不精确，需要简化和集中。这些都是来自真实世界的例子，他们迫使你修改测试过程和测试计划。

注意：当你制定计划时要始终将最终用户牢记心中。随着项目进行，你很有可能忘记你要测试的内容：具有某些特点的用户与产品的关系，而不是测试产品本身。

测试计划的组成部分

测试类型不同，或是你所在的组织对测试规范度的要求不同，测试计划的格式也是不同的。不过，通常会包含以下9部分，下文将对它们具体地描述。

■ 测试目的、目标和对象

■ 研究问题

■ 被试特征

■ 方法(测试设计)

■ 任务清单

■ 测试环境、仪器和后勤准备

■ 测试中主持人的作用

■ 收集的数据和评估方法

■ 报告内容和呈现

其中，由于测试中主持人的作用巨大，在第4章将作为独立章节详加讨论。其余部分则在本章阐述。

回顾测试目的和目标

文档的这部分描述了进行该项测试的原因。这里不是要你说出测试考察的具体目标或问题;相反，你的焦点或出发点应该是站在组织的角度，关注重点的问题。例如：

■ 测试旨在解决的问题是：公司的呼叫中心或技术支持先前上报过的问题吗?

■ 服务器日志或网站使用数据是否已表明公司网站的访客在某个流程中的某一节点离开，使得业务无法完成?

■ 公司是否最近公布了新规范要求所有产品在发布前进行测试?

■ 管理者是否意识到开发团队在此时了解真实用户是非常重要的?

测试目的拔高到较高的高度是合适的：因为后续的研究问题及描述部分可以将大目标具体到可测量水平。测试与组织的商业目标紧密相关这点非常重要，这样测试才会成为解决问题和探寻机会的最佳工具。

什么时候不进行测试

下面几条是产品应该进行可用性测试的非常模糊和不恰当的理由。这些理由可能很少会被书面化，通常是口头交流。但是，下列的测试理由并不合理，反而最终会影响整个项目。

■你可以提升用户体验(你只能测试产品部分的用户体验，而不是产品与用户的所有接触点)。

■其他人都在做可用性测试项目(其他人还有很多别的事儿呢)。

■ 用作可用性测试的会议室本月的第三周都是空闲的(会议室每天晚上也空着)。

■ Lou先生刚参加了新一届计算机协会人机交互特别兴趣组ACM SIGCHI的会议，并且学会了这种有用的测试技术(那先让Lou先生向公司高层推荐这一有用的技术)。

■ 你想要确认是否该类型的产品有市场需求的(这个逻辑显然反了，焦点小组和问卷才是更为恰当的在产品早期阶段使用的方法)。

你可能会说服自己，尤其是当你非常迫切开展可用性测试时，“我只是想做测试，我并不关心原因，我们可以后续再考虑测试结果。”短期来看，前面的任何理由都可以开始测试。但从长远角度看，如果你希望测试是开发产品中不可或缺的部分，你必须将测试与产品需求和组织的整体商业需求结合起来。否则，你会面临测试被当成短期流行的新技术的困境。

进行测试的最佳理由

以下清单列出了进行测试的合理原因，它们帮助得出有效的结果，并为未来测试奠定基础。

■ 你想确定是否你的两类主要用户都能很好地使用产品。

■ 你想了解提供文档是否可以解决界面中的某些普遍问题。

■ 你收到了大量使用产品中的投诉。你想确定这些投诉的本质，以及在今年开发预算下如何修复这些问题。

图5-1给出了一个示例：在线酒店预订网站的可用性测试目标。

图5-1 可用性测试的目的和目标示例

沟通研究问题

这一章节是测试计划中最重要的部分，它描述了需要解决的问题和研究焦点，以及与测试计划、设计和操作相关的部分。研究问题必须尽可能地准确、精确、清晰并且可测量的(或是可观察的)。就算是产品开发早期进行的探索性测试——非结构化的测试，仍需要精确地阐述你希望从中得到什么。

如果没有清晰简洁的研究目标，你会发现自己陷入了不利境地，执行的测试无法解答项目团队成员所关心的核心问题。或者，你会发现测试总是处于无休止的争论中，因为根本问题“测试的是什么”还未达成一致。从我自身的经历来说，我们遇到过准备工作推进着，但测试本身争议不断的情况，这其实还是测试目的没有落实成书面报告的缘故。

以下两个例子的研究问题就太模糊，太不明确了。

■ 例子1：当前的产品是有用的吗?

■ 例子2：该产品是否可以发布还是需要更多工作要做?

研究的困难之处并非是说这些问题毫无意义。而是说这些问题是不完整、含糊不清的，没有说明或暗含该如何测量或量化结果。依据此类描述来进行的测试最终会引起结果偏差。为什么?如果相关人员就需要解决的问题都无法达成一致，那你又如何确认已经找到问题的解决之道了呢?当然，在这样的情况下，通常是连研究问题都找不到。

下表列出了几类不同产品的研究问题，这些案例的研究问题恰当，重点明确。研究问题是在和开发团队或开发人员、技术人员、市场人员的讨论中形成的。如果他们很难归纳出测试目标或者仅仅提出了大概的问题或目标，也无需沮丧，这可能正说明：

■ 他们还没有做好测试的准备。

■ 他们需要更充分地了解测试目标、目的和过程。

■ 他们在将目标转化为具体的可测量和可观察的研究问题上需要帮助。你不要犹豫，是时候介入其中或提供帮助。

如果你发现自己很难设计测试方案和(或)合适的量表，又或是确定不了合适的终端用户，甚至是无法确定数据收集的形式，你不妨再回到研究问题本身，确认它们是否是清晰、需要进一步细化的。