反思1：论测试模型工作中的灵活性
敏捷开发中，测试开展时的灵活性最重要，那么测试人员应该在什么阶段介入，介入节点又是什么。当然也有对应的测试模型支持，比如敏捷开发中，大家熟知的H模型，和X模型。
H模型：软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。
X模型：X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。
什么意思呢。H模型更注重介入节点，整体交付，而X模型更注重片段交付，集成测试。
各有各的优势也完全符合敏捷开发中对灵活性的要求，但是也各有缺点。多任务交付时，H模型无法满足组件集成开发所要求的灵活性，而X模型也无法实现测试准备阶段的完整。
当然他们也是互通的，人员独立工作的能力才至关重要。比如说实际场景下，测试人员固定服务一个项目组而项目组内有不同的人开发不同的组件，那么测试人员可以根据各模块的完成时间分层介入测试，完成集成测试后进行系统的验收。比如测试人员同时服务多个项目而多个项目还重叠交付，那么可合理设定各项目整体的提测时间，来完成各项目的整体交付。
反思2：融合的效率
融合，从心理意义上指不同个体或不同群体在一定的碰撞或接触之后，认知、情感或态度倾向融为一体。
其实工作中业务合作，也是融合的一种方式，通过统筹目标下的各司其职来实现一个一个的团体目标。
至于效率取决于各岗位的融合规则，统一工作模式也是必然的。一个业务体中不同的岗位，不同的规则混合顶多算是假融合，所能带来的效率提升终归是有限的。
业务融合中效率的提升，类似辅助岗的综合能力意识也是需要锻炼的，比如测试岗，作为辅助，可以在实际工作中尽可能的去做一些更细的工作，如，线上bug维护，需求在固定节的同步，各提测节点的管理等。都是提升工作效率的方式。当然融合更多的还是应该主动去承担职责，主动打通不同岗位限制。这样的团队才能实现真正融合，带来意外的效率。
原文地址：https://www.cnblogs.com/liuhuaxi/p/9765256.html
