会议《测试团队过程改进实践分享》记录

---

前言

今天晚上参加了CKL 老师分享的会议《团队过程改进实践分享》，感觉收益颇丰，很有价值，结合此会议内容，发表一些自己的思考，作为记录,如有不合适的内容，可联系我删除，仅作为思考总结，无不良或商业用途。

---

一、前期问题思考

会议内容：

想要对团队进行改进，首先要思考一个核心问题

• 谁发起的：研发团队、业务团队、职能团队
• 谁对结果负责：明确责任主体、扩大责任主体、才有可能让过程改进可持续、可落地
• 如何度量结果：结合目标、调整改进、聚焦过程

整体的方向是什么？

• 从整体的流程上做优化、系统性的解决问题，标准化(保证下限)
• 以人为出发点，让团队更健康和活力（提升上限）

个人思考：

在这里提出两个整体方向，一个是从流程上解决问题，一个从人的方向解决问题，其实在会议中也说到了，从人的角度去解决问题，其实难度很大，一般是从流程上解决问题，在流程上问题解决了，再去以人为出发点，调整改进，这个团队的上限就非常高了。

我对这个观点非常认可，在我上一家公司中，我所在的部门，是一个流程非常规范化、标准化的部门，在这样一套流程下，其实冲突相对来说是非常少的，效率相对来说是非常高的。

后来进入了一家初创公司，从0-1开始，那种落差感是对比非常明显的，当时在我看来，流程和人都有非常大的问题，领导也多次想建设团队，首先也是选择从流程上做优化，搞效能等等，我也给我的领导提出了一些建议。

例如，1.发现测试团队不写测试用例，需求质量不高，很多问题到测试阶段才发现，返工成本高，后面编写测试用例，提前暴露问题；2.产品需求问题，在测试阶段反复扯皮吵架，理解无法达成一致，提出要增加测试用例评审，其实这个阶段也遇到了阻碍，上层领导觉得测试用例评审浪费时间，无价值，后来真正实施起来，解决了极大的问题；3.开发提测质量不高，责任心不足，测试推进有难度，提出提测演示，也遇到了上层领导的不支持，后来历时半年之后，终于实施，对开发的约束力非常明显，质量提高了很多；

等等这一系列的动作，其实都是在完善流程，只有流程上完善，规范化、标准化之后，以人为出发点，才是景上添花！

二、如何识别团队问题（发现问题）

1.访谈

• 思路：概述-事项-调研目标-团队反馈记录
• 例子：质量分析-生产缺陷多？-改善此问题，寻找原因-记录原因
• 目的：倾听团队的吐槽，发现团队的痛点，必要的情感交流

2.问卷调查表

• 目标群体：产品、测试、研发
• 思路：角色-阶段-目标-具体问题-等级-产品团队填写-研发团队填写-测试团队填写
• 目标：细化调查内容，收集更细节的信息

3.价值流分析法

目标：发现卡点，堵点

4.过程跟踪

目标：融入团队、深入和团队一起运作，参加到团队的流程中，观察事和人，不要一开始就盲目指责纠正

个人思考：
实际上，我个人觉得比起访谈、问卷调查表的形式，我觉得这个思路，更让我惊喜，非常有条理，有目的、有记录。

价值流分析法，是我首次接触，其实没理解太明白，个人简单理解，就是从整个流程中去发现有问题的节点，然后去改善，这个我是非常认可的，就像做测试，最讨厌的一句话就是这个bug你怎么没测出来，其实要想解决这个问题，不单单是测试一个团队的事情，要从整个流程中去找问题，看看是哪个环节出了问题，任何一个环节有问题，都会导致生产bug多。

三、质量过程改进案例（3-4个月）

背景：构建中心级统一测试规范

• 忌讳：发现一件事情解决一件事情，要有目标感、大方向

背景：时间紧张、测试任务重、所以没有时间编写测试用例？

• 调整研发节奏：确保测试有时间做测试用例
• 梳理测试点：可以不用那么细，但不能没有
• 用例评审：通过评审对齐缺失的信息，产研测再次对齐

背景：回归测试花费时间过长，测试成本高

• 变更内容评估：业务和技术双向评估
• 调整回归内容：哪些是核心且必要的
• 接口自动化：自动化一部分内容
• 外部探索性测试：引入外部力量

背景：测试资源明显不足，无法支撑当前的迭代需求

• 加人

背景：研发规范执行不到位，各节点交付质量无法保障

• 节点工具增加卡控，保障研发流程状态移动的准确性和及时性
• 例如：ShowCase、产品验收

背景：测试过程不可视，测试质量无法评估
测试过程闭环：

• 测试计划：测试计划对应一个或者多个迭代计划
• 用例线上化：支持在线Xmind
• 过程跟踪：改造后的测试计划概览支持过程可视，协助测试组长跟踪测试过程
• 缺陷管理：缺陷包含所选计划下的所有缺陷，统一跟踪管理
• 生成报告：自动生成测试报告，测试人员关注结论和风险即可

个人思考：
其实从以上例子来看，目前本人所在的测试团队，也是在这个方向进行完善整改，以上都是通用问题，基本所有团队多多少少都会有此问题。

在这个过程中，其实我也提出了一个自己的问题，和老师也进行了沟通，记录如下：

问题：
需求文档质量不高，很多问题需要测试在编写测试用例过程中发现，编写结束后，然后在进行需求澄清，造成的问题：
1、质量不高，会造成编写测试用例的难度、时间长度
2、需求澄清会相对延长，可能会达到项目进度中旬或者后期，研发调整成本提高

目前的解决方案：
1、向领导反馈，领导约束产品需求澄清的次数
弊端：并不能实际解决问题

建议：
在需求评审时，更多的提出问题，推荐书籍《需求实例化》

四、过程改进的结果度量

你的目标和业务目标是否有冲突？

保证你的目标和业务目标是一致的

你的价值如何体现？

主要是两个方面，测试效率和测试质量，简单来说就是量化质量为数据，去呈现自己的价值。

在这个过程中，有一句话我非常认可，测试效率提高了，测试质量不一定提高了，质量提高了，效率也不一定提高了。

研发团队价值如何体现？

五、能力迁移与更多的应用

1.你是愿意发生改变的人吗？

固定式思维：
规避挑战、痛恨变化

成长型思维：
欢迎挑战、拥抱变化

2.设身处地的去想问题，而不是高高在上的理论派

3.建议

• 提升识别和发现问题的能力，洞察核心问题
• 发现有主动改变意识的人
• 跟踪事情发生的变化

---