作者：张海云｜QE_LAB
本文首发于个人公众号探索式软件测试思维。
在很多公司敏捷转型的道路上，组织中如何安放测试团队都是非常头疼的一个问题。保留测试职能部门，怕有厚厚的部门墙，影响敏捷中开发测试融合。拆散测试部门，把测试人员安插到 Scrum 团队，结果测试任务被业务和开发的 “高” 优先级任务不断挤压，测试人员没有归属感，质量全局观丢失，一段时间后，线上质量问题不断爆发。甚至有很多公司在敏捷转型一段时间后，开始重建测试部门。
那么在敏捷下究竟该如何安放测试团队呢？
Cynefin 认知框架之父，Dave Snowden 曾经说过：我们要通过管理事物如何相互作用来进行管理，而不是通过尝试管理事物本身来进行管理。我们无法设计什么样的敏捷文化，我们要改变人们互动的方式，从而让不同类型的文化涌现。
因此无论测试团队在敏捷中如何组织，是派驻式还是矩阵式，是部落制还是强功能，如果无法改变测试与开发之间，测试与业务之间，测试与运维等各个角色之间的互动关系，就无法避免地会陷入质量的困扰。
在敏捷转型的第一步就是团队敏捷，开发测试融合，其实就是改变开发和测试的互动关系。
开发测试融合不仅仅是让他们坐在一起，一起开会，一起完成迭代。更重要的是他们要有共同的目标，他们要有使用自己不同的技能来最优的完成这个共同目标的意识。
我们可以把这个目标看成大家要共同持续、快速、高质量地交付价值。有了这个共同目标，开发和测试之间的互动就不再仅仅是开发写完 code，交给测试这样的互动方式。而是一个有机的整体，测试利用他质量视角的思维，在开发进行设计的初期，就可以给予快速的质量反馈。开发在开始写 code 的那一刻就把质量的观念深植于心，质量内建进代码。测试可以利用他对于质量的认知，通过代码规范，建立扫描规则帮助开发避免常见的质量问题，帮助开发设计更高效的单元测试用例。开发利用自己的代码能力，编写有效的单元测试，高效地准备数据。测试可以帮助建设流水线，让一切流程自动化，工具化来帮助我们提升效率等等。这样互动关系的改变，才是真正的开发测试融合。
一般来说，想要改变瀑布模式下长期形成的互动关系和意识并不容易。道理大家都懂，做起来就是另一码事。所以一般在形成真正良性互动关系之前，使用一些机制和实践先僵化，在实践中培养大家的意识，帮助大家看到良性互动的优势，再慢慢融合形成良性的互动关系。这里简单介绍几个相对常用的实践：
迭代目标的设置可以帮助我们建立全局观，但是我们在设置迭代目标时往往从业务需求层面，而质量往往是隐性的。为了在一开始培养团队的质量意识，可以先将每个迭代的质量目标显性化。等团队质量意识建立后，可以慢慢再去除。
需求条目的启动或者叫开卡，是更细粒度的针对一个故事卡，或者一个需求条目的启动仪式。当开发准备开始开发某个需求条目（故事卡）前，团队业务/PO、开发与测试围绕需求条目（故事卡）做进一步澄清，达成一致再进入开发的一个仪式。这个仪式改变了之前开发和测试通过代码移交的互动方式，在这个仪式上不仅可以进一步对齐大家对这个需求条目的认知，更给了测试一个机会从质量思维角度给开发更多的输入，从而避免一些未考虑到的场景和分支。
需求条目验收和需求条目启动是一对活动。它是当开发完成某个需求条目编码和自测后，向团队包括团队业务/PO、测试等进行 show case，团队对开发的成果提出即时反馈。原来开发通过把代码以及自测结果移交给测试，这种互动不仅效率低，甚至很多时候测试根本不看也不信任自测结果。需求条目验收的互动方式，不仅移除了耗时又低价值的自测报告，更加快了业务和测试对需求实现的反馈，同时也增强了测试对于需求呈现的理解，之后的测试阶段可以聚焦在更有价值的发现上。
在单元测试中我们往往遇到一个很大问题，测试人员不那么信任单元测试的结果。一方面是开发的单元测试用例写得多是开发思维的角度，很多是在重复测试。另一方面很多为了完成覆盖率任务，并没有很好的结果验证。单元测试因为涉及代码细节，天然的归到开发的职责范围，但是如果我们改变这种互动关系，测试和开发 Pair，测试可以利用他的优势来帮助开发设计更高效的单元测试用例，开发可以利用他代码优势迅速建立单元测试框架。这种 Pair 不仅是个产出单元测试的过程，更是互相学习，互相赋能的过程。
这些实践只是抛砖引玉，只要你从改变互动关系的视角出发，基于公司和团队的现有状况，相信一定可以发现更多更适合你的好实践。如果有什么新的发现，也欢迎来分享。
测试和开发互动关系的改变可以带来快速高质量的交付，但是是否交付了有用的价值，还需要进一步改变测试和业务/PO 之间的互动关系。在瀑布模式下，测试和业务/产品的真正互动一般开始于测试执行真正开始阶段，而这个时候业务/产品早就和开发沟通过一轮，他们更忙于与客户的互动，下一个需求的收集及分析的过程，很难与测试 on the same page。即使是测试提出了有效的问题，也早已木已成舟，代码都写完了，如果要推翻，代价有点大。于是很多别扭的实现一直存在在产品中。
敏捷中，这一互动关系得到了改变。从需求梳理会到迭代计划会，测试终于有机会在第一时间了解需求，提出自己的质疑，澄清需求的验收标准。终于有机会将他们在无数个 fail 场景，无数个线上问题获得的经验在第一时刻用上，预防问题的发生。同时，在需求条目验收，迭代评审等环节，加深了业务/PO 对整个过程的参与，加快了反馈的速度，同时也减少了测试与业务互动的频率，提升了互动效率，减轻了测试的压力。
当然测试和业务互动关系的改变，将测试推向前端，测试左移，对测试人员的要求也将会更高。你要有对业务的理解，对用户场景的熟悉，对架构的了解，对线上问题的沉淀。为了达到这种提升，也可以从一些实践开始，慢慢地培养测试人员的能力。比如可以从测试帮助写验收标准，沉淀测试需求提问模型，线上问题分析等。这里就不一一罗列。
敏捷转型带来的是快速交付，频繁交付，可是只有这个交付物能够发布上线才真正的产生价值，才能收集到反馈对下一步的产品方向提供输入。然而要发布上线就要经过运维这一关，在过去，运维是单独的一个部门，全公司的产品都由他们来统一管控发布和运维，他们有自己的优先级。当你读《凤凰项目》和《独角兽项目》时，最明显的感受就是研发拼命地改进，快速地交付，最终由于运维环节无法上线发布。为了改变这一互动关系，研发运营一体化（DevOps）的概念应运而生。借助容器，云等技术的发展，运维的工作方式也发生了巨大的改变，为打通研发和运维之间的部门墙提供了坚实的基础。运维和开发，测试的协作更为流畅。甚至有的团队在一开始的需求梳理会，迭代计划会就邀请相关运维参加，大家的目标不断地对齐，更好的互动关系帮助整个团队更为顺畅地交付价值。
同时，随着我们的产品系统越来越复杂，很多时候在 lab 里已经无法复刻线上的场景。在运维有良好的线上监控和分流手段的前提下，测试开始了右移。全链路压测，混沌工程，我们通过对复杂系统在线上的探索实验，来使得我们的系统更加强壮，稳定，可以应对越来越复杂的场景。这些测试都必定是测试和运维同学一起工作的结果，缺了哪个角色，都无法完成。
关于在敏捷中测试部门的组织架构到底是什么样，其实并没有标准答案。有的公司有独立的测试中心，敏捷运转的很好；有的公司运用部落制，也非常不错。但是我遇到更多的情况是公司的敏捷只是开发的敏捷，测试被隔离在外。本文从互动关系的维度希望能给大家提供一个新的思考视角，也许基于你所在公司的文化基因，你可以重新梳理测试和其他角色之间的互动实践来使得测试成为敏捷这个有机整体的一部分，为共同的持续高质量快速交付有用的价值而努力。