你懂什么是"结对测试"么？

如果说敏捷团队像一辆奔向终点的车，那我说测试人员就是整辆车的"车头灯"。它告诉大家现在到哪了，正在往哪个方向走。

这么说是因为，测试人员在其中提供了丰富的信息，让大家基于这些可靠的信息作出正确的决定。同时，大家要做一个思想上的转变：质量需要每一个人的贡献，而不专属于"测试"工程师。

image

敏捷团队中，测试人员不跟开发人员纠缠错误，而是帮助他们找到目标，共同为达到项目的最终目标而努力。配合着高度迭代的工作、频繁得到客户的反馈，动态调整测试计划、测试的执行。

这样看来，测试人员在敏捷团队中的角色显得越来越重要，好的测试人员甚至可以影响团队做出的决定和计划。

那在敏捷的环境下，我们的测试人员需要哪些转变？我们所提倡的"结对测试"又是一种什么样的存在？

测试角色的转变

价值探索者

边学习、边设计、边测试、边思考，这是敏捷测试人员应该习惯的方式。换句话说，就是测试人员自发进行的测试工作，在执行测试的同时根据所获得的信息来设计测试策略的方法，所谓探索性测试。

它强调要根据当前的实际情况来选择最合适的测试技术，进行测试。测试人员使用探索式测试从客户的角度评估软件的实际工作方式。它更注重的是「思考」和「学习」，不断的发现新的问题，找到新的价值点赋能产品。

image

建议发起人

测试人员的工作不再是纠错，他需要从产品规划阶段就参与其中，作为最熟悉产品的人，不仅仅是在开发流程末期验证开发是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。

质量反馈人

在 PO 定义产品和版本规划的时候，从测试人员的角度能提出对于质量的建议，并且将其固化在团队的 DOD 里。

在每次迭代的过程中，随时发现质量问题，看到系统存在的风险能及时反馈给团队，也能在一次次的迭代中将质量作为影响产品交付的重要环节。

在每个迭代结束的时候，结合 DOD 里面关于 Bug 的要求进行总结反馈，和团队一起分析导致质量问题的原因，并且制定改善计划，放在之后的 PBI 里进行跟踪。

结对测试

结对编程我想你已经非常熟悉了，两位程序员坐在同一台电脑前合作完成同一段代码。两个程序员具有相同的缺点和盲点的可能性很小，所以结对编程会获得一个更优的解决方案。

其实，结对测试是一个概念，他不需要测试人员时时刻刻跟不同角色坐在一起。因为彼此看问题的角度、思维方式的差异，能让大家互相取长弥短、优势互补，减少测试遗漏。

image

与业务分析人员结对

通常在业务分析师分析用户故事的时候，测试人员要与业务分析人员结对编写验收标准。通过与业务分析人员结对，测试能够更好地理解领域知识，从而有利于定义合适的测试用例。

测试人员能从测试角度添加的验收测试用例可以帮助整个团队对产品的功能性有更好的理解。

与开发人员结对

通常在实现测试自动化的时候，测试人员与开发人员结对是比较理想的方式。测试人员与开发结对完成简单的编码任务，在这个过程中不断树立信心。

这样结对实现的自动化测试质量相对较高，有测试意识较强的测试参与能够保证自动化测试测的是真正需要测试的部分，而以开发人员的编码能力也可以写出简洁可维护的自动化测试代码。

在测试人员消除了编程恐惧、具备编程基础后，安排测试人员与开发人员结对进行功能开发。在这个过程中，我们必须首先要帮助测试人员正视编写程序的必要性以及消除恐惧。

另一方面，通过与开发人员结对，测试编码能力也会相应有所提高，而开发人员通过与测试人员结对，测试意识也会增强，这有利于编写质量较高的产品代码，更有利于形成全功能团队。

与客户结对

客户是业务领域专家，通过与客户结对，测试人员能够更好地从终端用户的角度理解系统，从而定义或者增加更多的端到端的测试用例。

一旦测试理解了领域知识和终端用户的观点，其业务价值分析能力会有所提高，在团队需要的时候可以承担业务分析角色。

在用户验收测试（UAT）阶段，测试人员通过与客户结对，也能帮助客户熟悉使用系统，在必要时可以帮助客户解决一些系统问题。

小结

结对测试不是一个实践，而是一种思考，是一个方法，还是一种思维，甚至是一个运动。"职责清晰，边界模糊"是我们对敏捷团队中任何一个成员的要求。

更多原创推荐阅读：

如何度量敏捷开发团队

做一个"靠谱"的敏捷教练

你的团队属于部落的哪个阶段？

从"远程工作"到"分布式团队"

你真的懂"看板文化"么？

2020 敏捷产品基本盘

BVR 才是变革的核心

用"结构性张力"构建自驱力

学习型组织的修炼之道

洞察敏捷系统（一）

Lean UX 教你设计如何驱动产品

敏捷 + UX = 敏捷 UX

Scrum 实践之 DoD

敏捷产品管理之转型

image.gif

image