Question

糜家蔚@测试团队 2017-12-07

Test Fest 是什么

通常的测试流程为开发提测、测试执行、回归测试，缺陷与产品疏漏的信息反馈源与提交皆是测试人员本身主导，最后才将 “完成的需求” 交回到 “需求方”。

但在这个过程中，测试发现的问题并不能第一时间反馈到团队中各个角色，因此我们需要一种能够召集相关人员共同参与测试的方法，为产品质量多维度护航。

“The main idea behind the Test Fest conference was to create a platform where we can learn something new, meet people and discuss interesting quality related topics.” —testfest.pl

“Test Fest” 概念源自国外，是各方为了探讨产品质量方面的话题所建立的平台。

引鉴 Test Fest 的思想，我们公司内部的 Test Fest 便应运而生。作为公司范围内小型的众测活动，测试组人员会邀请所测产品的产品经理、开发、设计、运营、客服，对于当下阶段的产品共同进行探索性测试，发现产品 Bug。

Test Fest 能解决四大测试痛点

1) 多方沟通跑断腿的为什么总是测试人员？

有一份很庞大的需求文档，从诞生开始，它可能会被更改 N 次，它可能会被不同角色理解成不同版本……

又有一份很零散的需求文档集，所有的人只熟悉自己负责的模块……

当以上两种情况在测试阶段被发现，全部靠测试人员去协调沟通，未免丧失效率。沟通是可以面对面的！

此时，一场 Test Fest 对于产品经理来说，可以第一时间接触到产品。在产品刚有雏形的时候来验收产品，避免研发过程中需求理解错误，减少修复成本；亦可以在产品后期探索到是否存在产品层面的缺陷导致设想的需求未被落地，及时作出调整并周知大家。

2) 为什么总是上线了才发现这是 Bug?

用户触达功能入口的变更，文案的变更，这类需求的实现没有 Bug 并不表示无后顾之忧了，

也许对客服、运营人员来说可能会引起一系列话术的更替。

作为测试，经常被要求测得 “又快又好”。在有限的测试时间里，我们需要沟通新需求、设计测试方案、执行测试用例、回归已解决问题、评估版本风险等等。紧凑的发布节奏下，决定了测试内容是有取舍的，从而会忽略一些我们自认为的 “不重要” 测试项。

此时，一场 Test Fest 可以让每一个角色都融入到产品中去，站在自己的工作维度上测试产品，更多了解自己的产品，发现产品的优缺点，提出自己对于产品的想法，多维度审视产品质量。

3) 兼容性测试如何覆盖更多？

一般在测试工作中，资源有限，测试时不能兼顾到所有机型，

然而某些缺陷只在特定机型上才会暴露，如果等到产品上线发现适配问题再修复，修复成本会很大。

Android 用户终端的多样性决定了几乎所有产品都不可能做到覆盖完全，最常见的有网络、系统、机器品牌等，一旦出现问题，发布后影响的是该类环境下的所有用户。我们设计测试场景时，总是尽可能把自己想象成真正的用户，从他们的视角去测试。

但不得不承认，很多时候测试结果和发布后用户的反馈是不相符的。比如性能方面，测试人员手中的设备反应快和流畅，到发布后却有用户反馈慢和卡。用户数据的复杂性是任何发布前的测试环境无法完全模拟到的。

此时，一场 Test Fest 分配到所有参与人员不同的机型，短时间内的探索性测试即可覆盖主要功能路径，易于暴露机型问题。

4) 新功能体验如何？

“Eat your own dog food.”——不多用自己产品，如何做好自己的产品？

在我们的实际执行过程中，参与人员会热情地讨论某个功能竞品是怎么实现的，该如何优化。每个人说出自己的见解，一些体验类的建议也因为在意的人数众多而将测试 issue 转为产品需求。

测试人员如何举办 Test Fest

当我们有明确的测试目标后，可以逐步梳理过程中可能遇到的问题，并提前扫除障碍，形成有效的测试指导书，提升整体效率，主要分为以下四步。

第一步：前期准备

1. 确定主持人。

   主持人通常选择所测产品的主要测试人员担任，在 Test Fest 过程中可以对参与者的疑问及时作出响应。

2. 根据测试用例，将所测产品以模块划分，并标注测试类型。

   主持人可以根据模块与测试类型进行介绍，也引导参与者反馈问题时能清晰地描述。

3. 为划分的模块设计 1～3 个指定的测试场景。

   规划全面的场景覆盖并分配到人，避免多位参与者在同一个路径上进行探索测试。必要时可以指出需要关注的测试点。

4. 确定测试反馈时应该指派给哪位对应处理人，处理人应为所测产品的测试人员。

   只有测试人员清楚知道截止当前哪些问题是已知未修复的，对应模块的开发负责人是谁，后续缺陷整理与上报可以快速展开。

5. 发出邀请，确定参与人数。分配好测试设备与所测平台，并预装测试产品。

第二步：任务分发

主持人介绍此次 Test Fest 的测试范围，为大家分发测试设备或指明平台，告知各参与者负责测试的模块并讲解需求，给出缺陷提交的链接与格式，标明对应处理人。

各参与者不仅要站在自己角度探索产品，也需要执行被分配的任务。

第三步：问题收集

在测试过程中需要反馈的 Bug 或者需求先当场口头声明出来，确认不是使用过当，则提交该反馈至缺陷管理平台内的对应项目中。

缺陷标题格式开头写明 “[Test Fest]” 或 “[Bug / 建议 / Bug 转需求]”，指派给对应处理人。

第四步：后续工作

1. 反馈问题过滤。

   对应处理人统一审核测试反馈，将 Bug 指派给开发人员，建议与 Bug 转需求指派给对应产品经理。同一个 Bug 在不同的设备、平台上会有不同的表现，因此经常会有相似 Bug 出现，或直接重复，这样的 Bug 需要处理人过滤。

2. Bug 优先级管理与后期回归测试推动。

   根据开展 Test Fest 时所处的项目阶段不同，获得的测试反馈中各类 Bug 数量的比例也有所不同。

不同测试阶段引入 Test Fest 的效果

1) 项目刚进行完首轮测试，缺陷修复后

根据我们近几次的实践经验，首轮测试后的 Test Fest 所产生的有效 Bug 达到 70% 之多！处理人需要将有效 Bug 适当进行分类：

• P0 — crash 或 block 问题
• P1 — 常规问题
• P2 — UI 问题
• P3 — 体验问题

2) 项目经历两轮测试，缺陷总量增加但趋势可控时

同样，我们统计了最近三次的实践结果。两轮测试后的 Test Fest，有效的 Bug 约占 50%，其余反馈中 20% 为产品建议，30% 为被开发拒绝的 Bug 或与测试阶段所提重复的 Bug。

本阶段被拒绝处理的 Bug，测试人员需要求开发标注拒绝原因。有条件的可以让开发讲解该 Bug 是如何引起的现在遇到的修复难点是什么，大家一起评估下一版是否通过其他方法修复后才算结束。

3) 项目经过多轮测试，所剩 Bug 为个位数时

参与人员的反馈经处理后，可能有效的 Bug 只有 20%～30%，以产品建议类为主。建议类 Bug 一般是对产品需求的看法，并不是所有的意见都符合产品逻辑，也无法从鉴定是否为 Bug 的角度去判决，处理人需要及时流转给产品经理，也许这些建议能给产品经理带去思考的火花。

由于此时项目处在即将发布阶段，所提出的 Bug 在此时修复，如果代码改动太大，可能会引发其他的 Bug，需要与开发评估改动范围，避免因小失大。

如何让 Test Fest 成功落地

让非专业测试人员百忙之中抽出两小时时间用于测试产品，一开始听闻还是难以被接受的。那如何发起并长久推行下去呢？并且如何确保非测试人员完成测试的质量？

1) 主持人需要做 3 种努力

• 天时：优先选择下午 2:00～5:00 这个时间段。通常来说，整个团队在这个时段的平均工作效率不高，可以利用这个时间组织开展，缓解时间占用的问题。主持人需要根据实际的执行情况调整结束时间。
• 地利：将参与者聚集在一个宽敞的会议室或沙发间，才能放下手边的工作，专注于测试产品，同时也能让参与者体会到这与正式工作不同，轻松的氛围亦可以缓解工作疲劳。
• 人和：工作的顺利进行需要有总指挥的宏观推动，项目经理对 Test Fest 的认可可以一扫团队其他成员时间分配上的顾虑；适当设立荣誉激励与物质鼓励也是不错的手段。

2) 被测内容具备 3 个特征

• 覆盖度广：无论在网络、设备机型、用户操作方式、应用类型等方面的覆盖度都是惊人的，单个测试人员需要大量重复地执行测试。
• 时效性低：由于测试活动的举办需要经过前期准备、任务分发、反馈收集、反馈跟进等环节，耗时较长，因此不适合时效性特别高的测试。
• 复杂度低：技术类需求、专项测试需求需具备较深的知识基础，考虑到培训成本，沟通成本的等因素，因此这类需求不适合。

3) 巧妙地设计测试用例

筹备 “场景化测试”，而不是单纯地执行测试用例。

我们希望非测试人员带来的不同视角与维度的测试，并从中给予专业测试人员启发，因此设计简单的测试场景，能控制参与者在有限范围内的 “自由发挥”（探索性测试）。当然，如果有明确的测试侧重点，也需要清晰地告知参与者。如此，便能保障是在 “核心功能” 被触达到的情况下开展众测。

Test Fest 的成效

通过我们的逐步摸索和多次尝试，证实了推行 Test Fest 可以暴露出产品需求被误解后实现的问题、产品的兼容性问题、产品上线后所需联动的其他支持问题。与此同时，测试效率和质量也有明显提高——在汇聚人力、提升覆盖度，以及发现更多维度等方面，Test Fest 都有很好的表现。然而我们在 Test Fest 上投入的成本却很低，每次开展平均耗时 2 小时，真正的 “高 ROI”！

另外，Test Fest 在内容上也可以进行拓展。比如，作为产品层面上长时间未涉及到更新的功能，在本次迭代中需要改进，可以作为回顾开展测试活动；抑或是我方产品主要功能与竞品相似功能进行对比的测试活动。活动中，可以是邀请非技术人员进行功能测试，邀请技术人员进行性能测试等维度。

可以拓展的不止于此，需要结合项目实际情况，在实践中不断摸索前行，本文不再详述。

总结

一场效果出色的 Test Fest，可以让每一名参与者都是全情投入，积极反馈。在这个过程中不仅成为产品常规测试的一个有效补充，也为其他角色了解测试搭建了一个很好的平台。