一、测试团队的弊病
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耗时久
诸如此类的问题常常会导致研发人员与测试人员直接的沟通“不顺畅”：
测试人员的苦恼：花了很久还原数据并图图解给开发看证明有缺陷，开发人员并没有太“当回事”；
研发人员的苦恼：测试数据/第三方/测试环境等等非代码问题，却要耗费时间去排查，还不如多开发两行代码了
这两种苦恼的根本矛盾点在于二者对于质量的理解不同。测试人员对标的是上线质量，而开发人员对标的是代码层面的质量。