一、测试团队的弊病
1、片面强调流程
流程能解决一部分问题,不能解决所有问题,还是应该找到根本的解决方案。
目前越来越多的项目组,在业务比较成熟了以后,为了“减少”/"规避"上线后的故障,采用增加流程审批的方案:
各种修改的审批
各种review的增加
小到一行代码的改动,大到一两个月的项目,统统走相同的流程。结果造成流程也就变成了所谓的流程,大项目不能通过其控制风险,需要快步走的小项目处处束手束脚。
2、业务耦合严重
上下游业务区分不明,导致经常发生故障(所以耦合十分紧密的业务,十分适合在一个团队以上进行;团队是否能cover整个业务,如果不是,还要对整个业务质量负责,显然是不合适的。
比如,亲身经历过的一个业务,大致依赖关系: 数据仓库(团队A)-->数据筛选排序(团队B)-->用户下单(团队A)
测试依赖关系:数据仓库的N多个场景(团队A负责)-->数据排序的M多个场景(团队B负责)-->影响之后的下单显示(团队A负责)
团队B,不清楚数据仓库逻辑,导致常常找团队A造数据;
团队A,不清楚负责的数据如何展示,导致数据场景覆盖不全
结果:团队A数据仓库问题导致的故障,却要和团队B扯皮,为什么没有测试出来;
3、缺少上线前演练
线上故障中有关配置修改错误导致的故障常常会发生,特别在广告搜索、策略算法业务中,大约 占比30%(实际项目中得出的数据)。大多数针对此问题,采用的方案是:配置修改增加审批。非团队核心人员、非leader审批不允许上线。
从谨慎上线角度看,这种方法无可厚非。但还是想强调预发布环境的重要性。无论事先准备多么充足,如果从来没有预发布演练过,仅仅靠人为审批或review,其实风险依然存在。
上线前预发布演练的思路:
前端演练;
后端演练
数据演练
演练的最理想的状态:除了性能外,和线上完全是一样的,但又完全隔离与真实用户
这里要强调一点的是,尽管有审批、预发布演练,但以下问题,仍然要万分小心考虑,因为很可能导致故障哦:
1)代码异常逻辑问题
此问题的彻底预防,可以添加code diff,最好添加方法的单元测试
2)边缘场景没有覆盖充分
这是比较难解决的一类问题,开发人员常常对此修改评估不足/评估不到,测试人员面临的困难常常是时间紧任务重,无法100%覆盖全部场景。
4、测试工具逐渐脱离业务实际需要
涉及到测试工具,大多数公司基本有以下几类:
- 公司级别的工具组。服务于整个公司/至少若干事业部的工具,有专职的开发测试团队来维护。当然这工具,尤其在成熟的大公司,比较成熟和好用了,工具主要是修修补补或者版本重构/升级方面的需求。这类工具当然不太会针对某个业务线进行单独开发,或者和特定的工具结合起来。为了使用的方便,具体的业务线在有人力的情况下,通常会自己有针对性的适配。
- 业务线内部的工具组。这类工具大多数由项目中具体的问题开发出来的,后来发现可以推广,就做了不同业务线的适配了。坦白说,这类工具是实实在在可以产生业务价值、个人亮点的产出了。但这种工具越来越成熟后,常常为了统一规范,要逐渐演变到各种流程、冒烟测试中,来作为整个质量团队的亮点了。
- 个人自发形成的工具。这类工具由项目中具体的问题开发出来的,后来发现可以推广,演变成业务线内部的工具。
有那么多的测试工具来提高效率固然好,但现在在测试工具的使用中,从质量leader管理角度更多去推动下面各个业务线的接入,各个业务线人员更多强调接入率、通过率等等指标。越来越少人重视测试工具业务需要的迫切性、在业务中实际产生的作用(例如:发现多少问题等)。
二、研发过程弊病
1、研发目标片面
这里是说研发人员需要明白为了什么而研发。
项目中通常会碰到以下三个层次的研发人员:
- 大牛级别(10%)。研发的目的是更好服务用户。他们工作特色:主动完成需求功能;完成之余可针对当前问题、研发优化给出建议;
- 老鸟级别(80%)。研发的目的是更好实现产品需求。他们工作特色:可以比较好的完成产品需求,对积极修复问题、团队成员沟通顺畅;但也会存在一些瑕疵:例如研发中的合作,后端改接口不通知前端;
- 新手级别(10%)。研发的目的是尽可能实现产品需求。他们工作特色:能够磕磕盼盼的实现产品需求,但提测后问题明显较多,代码中对异常的处理和考虑非常欠缺。这其中有一部分是态度问题:只code,不关注交付是否可测;与第三方接入对接,只关注代码实现,其他改不关心。
2、研发团队忽略研发氛围
目前,大多数研发团队管理方式是结果导向型:leader不强调成员提测的质量等,大多数更强调业务理解,技术理解等方面,以发布结果为最终判断标准。只要发布结果没有问题,就万事大吉。
个人以为,提测质量不仅仅与研发人员对业务的理解、技术掌握程度有关,更和自己思维的严谨度、自测水平有关,这同样需要在团队内形成推崇的氛围。
高层次的研发应该是这样的:
考虑问题全面,思维严谨(衡量标准:提测时的主流程全通)
自测水平过得硬(衡量标准:bug总量少)
业务/代码 烂熟于心(衡量标准:有了bug修复时间短)
建议: 评价开发的时候,除了本身的硬性指标外,思维严谨性,合作,主人翁意识尤其重要。研发团队内部,需要推崇开发人员本着产品质量来开发。开发和测试重要的就是配合、配合、配合,全员为质量负责,为用户打造品质卓越的产品。
3、与测试人员之间的无效沟通
开发人员在整个项目推进,质量保障方面有着承前启后的作用:
- 研发质量。这里指最终提测的质量。这部分质量绝大部分取决于研发人员的“水平”,而且对之后的测试质量有着很大的影响。
- 测试质量。承接了研发质量,有直接对接了上线质量。在整个测试周期中,测试人员与研发人员大交道的目的无非的bug的修复与验证,这涉及二者直接的沟通,沟通的目标是推进质量的推进,凡是违背这个目标的沟通,均是无效沟通。所以,这里有几个值得探讨的bug问题:
1)由于测试脏数据导致的问题
2)由于第三方接口问题导致的问题
3)由于测试环境问题导致的问题
4)不易复原的bug耗时久
诸如此类的问题常常会导致研发人员与测试人员直接的沟通“不顺畅”:
测试人员的苦恼:花了很久还原数据并图图解给开发看证明有缺陷,开发人员并没有太“当回事”;
研发人员的苦恼:测试数据/第三方/测试环境等等非代码问题,却要耗费时间去排查,还不如多开发两行代码了
这两种苦恼的根本矛盾点在于二者对于质量的理解不同。测试人员对标的是上线质量,而开发人员对标的是代码层面的质量。