点这里👇星标关注，获取最新资讯！
谢鹏，中国民航信息网络股份有限公司重庆分公司，资深软件测试工程师，PMP/ACP/CSPM-3/ISTQB-TA/OBCA/信息系统项目管理师/软件评测师，研发效能（DevOps）技术工程师（中级）学员
一、为什么还有独立测试团队
都DevOps了，为什么还有独立测试团队存在？或者说独立测试团队还有存在的必要吗？回答这两个问题之前，我们先回顾一下软件测试（Software Testing）的发展历程。软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证(SQA)的主要职能，包含软件质量评价的内容，Bill Hetzel在《软件测试完全指南》(Complete Guide of Software Testing)一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。1983年IEEE定义了软件测试及其行业标准（IEEE829）,软件测试是“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。软件测试是由于软件开发编程行业高度成熟后所形成的产物。
二、敏捷框架选择与设计
再来看看敏捷带来的收益，只要团队想要达成其中的一个或者多个目标，那就大胆尝试。经过调研和试点，独立测试团队希望通过敏捷解决的核心诉求主要表现为：任务管理更加清晰透明、打破业务壁垒团队共责、提升团队活力和积极性、推进持续改进和自组织。
接下来是选择合适的框架，不存在最好的框架，也没有一种框架是完成适合独立测试团队的。我们选择了Scrum+Kanban+XP相结合，并基于独立测试团队特点进行了裁剪和调整。
PO（Product Owner）：可以由测试经理或测试负责人担任，负责Product Backlog和Sprint Backlog，负责决定做什么和为什么做这些，代表项目团队和客户。 SM（Scrum Master）：传播敏捷思想，保证Scrum流程，促进团队工作，精心组织Scrum各种仪式，确保团队高效和紧密协作，保护团队不受外界干扰；SM可以是外部教练，但一定不能是团队内“有身份”的人。 ST（Scrum Team）：均由测试人员组成，按时交付成果，自组织的团队。
产品待办事项集合（Product Backlog）：以用户故事的形式表示完整的测试需求列表，可以是来自客户或其他团队的测试任务，也可以是测试能力提升和改进事项；同样推荐As a , I want , so that句式。 冲刺待办事项列表（Sprint Backlog）：一个冲刺目标阶段内的用户故事列表，这些用户故事来自Product Backlog，每次冲刺前，PO根据交付价值，将优先级最高的用户故事放入迭代。 增量（Increment）：是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，即完成的测试任务。
专注（Focus）
勇气（Courage）
开放（Openness）
尊重（Respect）
承诺（Commitment）
Sprint计划会：在每个Spring开始之时召开，由Product Owner、Scrum Master和Scrum Team全体人员参加。主要确定当前Sprint的目标，选定并估算当前Sprint要处理的最具价值的用户故事，创建Sprint Backlog。 Sprint冲刺：一个固定时间长度的测试交付周期，建议为1-2周。 每日站会：15分钟，不讨论问题细节，每个团队成员回答“本次会议之前，自己做了什么？本次会议之后，自己打算或计划做什么？目前，是否遇到了阻碍自己的问题？”。 窗口期：每个Sprint内1-2次，在不影响Sprint周期的情况下，设置窗口期允许必要的变更，以更好响应测试需求，避免因实施敏捷引起其他团队或关键干系人不满。 Sprint评审会：全员参与，评审和验收测试结果，PO负责最终确认和拒绝，可以视情况邀请开发参加。 Sprint回顾会：用来回顾在当前结束的Sprint中的工作，进行经验的总结、反思，并拟定相应的改进措施。
2.2 量身打造的看板
推荐使用JIRA电子看板投屏或物理看板，自定义泳道，团队任务和负载透明化。
2.3 XP之结对测试
倡导结对测试，根据团队成员能力特点绘制能力象限图，结合任务认领情况AB角结对测试；提升交流与协作、提升测试质量、打破业务壁垒提升能力互备。
2.4 独立测试团队与开发团队协同
三、实践流程
3.2 驻场转型
2-4个迭代，由经验丰富的敏捷教练驻场指导，参考独立测试团队敏捷框架，带领团队成员适应各自角色，熟悉相应工件、仪式；接受必要的试错成本，敏捷教练以观察者身份参与和记录问题，引导团队不断思考和改进；物色和培养团队自己的SM。
3.3 自驱运转
4-6个迭代，由团队自己的SM组织各种仪式，鼓励团队自驱，形成团队自己的节奏和“套路”，专业教练仅作为受邀嘉宾参与回顾会；必要时SM可轮值帮助团队更快理解和适应敏捷模式。
3.4 评估与建议
从共责、需求、响应速度、交付保障、沟通、治理六个维度，每个维度又分为阻碍进步、中立保守、相互配合、运转流畅、适应变化、改革创新六个等级，随机访谈团队成员，综合评判团队敏捷成熟度，并给予分析建议。
3.5 持续改进
四、经验总结
推行敏捷有助于独立测试团队更好的融入DevOps研发体系，是在提升效率和保证质量之间寻求平衡的一种破局之法。局部的独立是为了更好的融合，量身打造的个性化敏态共同筑牢组织的稳态。
参考文献
[1]《软件测试完全指南》(Complete Guide of Software Testing)，Bill Hetzel
[2]《Scrum官方指南》，Ken Schwaber、Jeff Sutherland
END
