作为测试经理的两年，我都做错过哪些事？

布满荆棘的人生 2023-09-24 15:30 2阅读 0赞

我是一名测试经理，在过去的两年时间做了两件事，团队从0到1的搭建和从QC到QA转型，这两年没有什么精彩的故事，都是一次次的尝试-失败-尝试的过程。

**公司背景**

近两年主要做项目外包，客户是央企，我们做完的项目要过他们的测试部验收，测试超过两轮要罚款。他们通过的标准是一般问题不超过三个，轻微问题不超过五个。

**第一次失败**

**冒进的左移**

团队组建后，我等到了第一个全新的项目A，这个项目对我和我的团队来说都是至关重要的，我们需要这个项目来给自己树个标杆，开个好头。

于是我把过去两年我认为最有效的测试方案——测试左移应用到项目，在项目经理的配合下，我们将项目按模块进行了拆分，并配合着制定了开发计划和测试计划，一切都有条不紊的进展着。

随着项目的推进，一个致命的问题暴露了出来——返工。大量的工作被推翻重做，项目周期也延迟了一个多月。在这一个多月中，测试和开发团队都在不断的返工中度过，项目最后的交付质量也是惨淡收场——验收五轮。

项目结束后，我反思了失败的原因：

**1、测试方案激进**

在对项目的整体难度和项目团队能力有充分认知前，贸然的选择了最激进的左移，致使测试工作节奏混乱，在后期的不断返工过程中，成员情绪也有很大的影响。

**2、里程碑拆分不科学**

在开发计划制定好之后，匹配测试计划时，单纯只考虑了完成了哪些就测试哪些。完全没有考虑到模块间耦合的问题，没有考虑后面开发和修改bug对已完成工作的影响，也是造成返工作主要原因。

**3、变更失控**

这个项目的需求前前后后修订了几十版，一部分是客户频繁的提出新的要求，另一部分是因为在项目进行过程中自己发现的的坑，不得不一次一次的填坑。变更失控，势必造成无休止的返工和延期。

**4、低估了项目难度**

项目初期测试针对项目数据方面的逻辑设计了数据模型，但是随着项目的不断深入，测试和开发达成的一致被不断的推翻，甚至在最后交付前，核心的数据逻辑测试和开发还发现有部分分歧。

错过了两次补救的机会：

*  在第一次出现返工时，没有认识到根源问题，仍然安排测试人员全程跟进，错失了第一次调整方案的机会；
 *  在变更频率表现异常时，同样没有深入的挖掘问题，还在盲目一条路走到黑，错失了第二次调整方案的机会。

**总结**

所有的方案确定都要依赖于对环境的充分了解和分析，每一个项目都是独特的，盲目的套用会死的很惨。

每一个问题都不是个例，它背后一定有隐藏的原因，深入挖掘问题才能避免更多的问题出现。

**第二次失败**

**不灵活的“灵活”**

团队组建之初，项目并行是我们面临的一个巨大的考验，于是在项目B上，我尝试了团队的灵活切入切出，希望实现人员的可插拔。

在项目B中，每个阶段开发完成我都会尝试更换一名测试人员，希望锻炼团队面对项目时的灵活性，项目B前前后后参与的测试人员有5名，最后的交付质量同样是五轮验收。

又是熟悉式场景，却有不同的原因：

**1、项目盲区**

人员变更势必造成对项目和需求的盲区，每个人负责自己的阶段和模块，即使多做一些，仍然不足以覆盖到整个项目的盲区，盲区就Bug的温床。

**2、人人负责=没人负责**

当所有参与项目人都知道我只会在项目中工作一小段时间，当要求所有参与项目的人对项目负责的时候，就是没人会对项目负责。

**3、测试工作很失败**

在对客户验收的问题做整体分析之后，发现75%的问题是因为我们对客户验收标准的不对齐导致的，如兼容性要求，需求文档要求，用户场景要求等，都被我们忽略掉了。

**总结**

灵活可插拔，并不意味着所有人都需要频繁的变动，1+N的模式会更好：

*  即一个负责人，加上N个可调整的测试人员；
 *  每个项目有且只有一个负责人对项目负责，亘古不变的真理；
 *  对齐标准永远是第一要务，要芝麻给西瓜的事千万不能干。

**第三次失败**

**成本才是王道**

公司的项目全部都是功能测试，本着提升团队素质和产品质量的初衷，开始推进接口测试。

在给团队做了两期的基础概念加工具使用的培训之后，找到项目经理选定了一个周期相对宽松的项目开始了接口测试之旅。过程整体符合预期，两周的时间完成了用例设计到测试的全部内容。发现了一些项目问题，团队也积累了实战经验，但是还是失败了，这次失败不是这个项目失败了，而是接口测试没有推广下去。

这个原因就显得更为冷酷了：

**1、成本压力**

接口测试的介入，并没有减少功能测试的时间，增加的十几人天都是额外的成本。对项目质量的提升因为没有对比数据，所以无法体现。

**2、周期压力**

测试需要较完备的接口文档，才能支撑测试。理论上接口文档应该在项目设计阶段定义，但实际项目并没有接口文档，swagger的信息也是简单的不能再简单了。开发人员需要额外的时间编写文档，测试人员需要额外的时间测试，客户又不会给足够的周期。

**总结**

扩充技能树是好事，但是目的应该是节省成本，任何不考虑成本的投入都是耍流氓。

技能的应用应该更灵活，比如在里程碑中加入接口测试做验收，事半功倍，全部放在集成测试中必然不会成功。

**第四次失败**

**内部客户大于外部客户**

有一天老板找到我，说有一个纯测试的项目需要评估一下。拿到信息之后做了基本的梳理，政务类项目，逻辑简单但是表单超级多，搬砖的活。

将信息反馈给老板并与老板再次交流之后我的结论是：做不了。团队当时处于满负荷工作，后来与老板交流了几次，我的反馈都是做不了，最后老板找了几个在校的实习生来协助我，于是开始接触客户。

在和客户的几次交流中，客户的诉求是希望能节约成本，但是我还是坚持质量第一位，最终客户接受了我们的方案。项目最终顺利的做了下来，80多人天，900个Bug，40000条用例，数据看还不错，为什么也算成失败了呢？

**1、没有满足内部客户的诉求**

老板带过来的项目，可能有很多的考虑，比如利润、比如搭上新的客户等等。我在接收到信息之后，第一反应是我的团队消化不掉就不要做了，完全没有考虑到要替老板攻下这个山头。

**2、没有满足外部客户的诉求**

在客户频繁的表达想降低成本的时候，没有站在用户的立场，可能政务类项目的质量标准和其他客户并不相同，可能这只是个演示版本，后期还会有更大的变动，种种可能都没有去过的考虑。虽然客户认可了我们的方案，但是结果就是客户再也没有和我们进行测试类的项目合作。

**总结**

对待内部客户应该像是对待家人，解决他们的问题应该是放在第一位考虑的事。就像孩子过来跟你说我饿了，你的第一反应应该是我要想办法给你弄点吃的，而不是我没有钱。

对待外部客户应该挖掘核心的诉求，满足客户才能带来长期的胜利。

**第五次失败**

**裁员风波**

这是个敏感话题，对我产生了比较深远的影响。团队有一个小姑娘，在公司的一年中整体变现平平，且呈现了较明显的下滑趋势。有三个问题让我开始认真考虑：

*  与团队合作的时候经常发生争吵。有一次他们两个人在针对一个测试点交流的时候，另一位同事问她，这个有没有测过，小姑娘在办公室就急眼了，意思是你不信任我就自己干吧；
 *  工作时间总是玩手机，消极怠工，负面情绪对团队产生了比较大的影响；
 *  Bug产量持续垫底，我对比了她参与的全部项目，Bug数量都是最少的，且差距非常大。

在持续观察了一段时间之后，综合考量了产出、贡献、资质、成长空间和对团队带来的影响等方面，最终决定做辞退处理。由综合部门出面处理了这件事情（协商处理，没有发生法律风险）。

这件事又为什么定义成失败，主要两方面的原因：

**1、没有对综合部门做到足够的支撑**

在做出辞退决定时，并没有第一时间给予综合部门足够的数据支撑，最终可拿出的数据维度也相对单一，为综合部门面谈造成了不小的困难。

**2、没有及时反馈**

在团队成员出现问题的时候，没有在第一时间做出反馈，或者在反馈几次之后丧失了对成员的信息，导致情况发展到了一个大家都不太原因看到的局面。

**总结**

淘汰机制是公司层面制定的，但是部门内部应该有足够的绩效数据积累，在必要的时候可以给公司提供客观公正的数据。

及时反馈在团队管理中是非常重要的原则，当发现成员行为出现偏差的时候，第一时间给予反馈，及时纠偏才是对他、对团队负责任的表现。当你想要放弃一个人的时候，其实也是放弃了自己。

**第六次失败**

**搭对不匹配**

前面提到的1+N模式，是我们团队长时间使用的搭对模式。

期初效果明显，两人合作，一人负责在项目中磨合得很顺利，测试质量也呈现了上升趋势，其中一个项目还实现了我们第一个二轮验收通过的突破。

但是在年末的时候，突然就发生了一些意外状况。其中一组是A、B两个人搭档，A是有一年工作经验的小姑娘，作为负责人。B是实习生转正的小弟弟。A姑娘能力特别强，执行力强，认真负责但是有暴力沟通的问题，B弟弟态度也端正，就是特别轴、认死理。

B弟弟还有一个有意思的事，有一次部门内部分享是B弟弟主讲，在过程中提到了很多知识点，但是这些知识点不是这次分享的重心，而且他也没有准备这些知识点的内容，造成了大部分时间都在讨论一些与分享无关的且没有结论的内容。分享结束后，我找B弟弟交流了一下，说非重点内容可以带一下就好了，不需要太展开讨论。结果在第二期的分享时，B弟弟整场说了不下20句，这个点你们自己百度吧，我不讲了，走了另一个极端。

说回来，他们两个合作比较长的时间都还相安无事（后来证明是我自己以为的相安无事），直到一次因为一个Bug的处理发生了比较直接的冲突，正好我在办公室。

冲突结束之后我先和B弟弟交流了一下，B的意思就是对A的经验非常不屑，觉得自己工作几年之后也会有经验，感觉让A负责项目他非常委屈，限制了他的发展。之后我又和A交流了一下，核心就是B做得不对（事实证明确实是B做得不对）还不听她的，经常是她自己承担非常大量的工作来弥补B的过失。

在这件事上，我没有选择和稀泥，安抚并引导了A的情绪，批评了B的固执，结果就是B没过多久就离职了，而A则快速成长起来。

对于这件事的结果，我觉得不算是失败，但是导致这一结果的过程却是彻底的失败：

**1、人员分配考虑不全面**

在搭对的选择上，我考虑了能力的差异，和后期人员培养的规划，漏掉了性格的因素，这恰恰也是导致失败的最重要的因素。95后的孩子都很有个性，将两个尖锐的点放在一起，就会产生不可逆的后果。

**2、对团队观察不够细心**

没有从平时的交流中发现端倪，当问题明显化之后，再想弥补就几乎不可能了。

**总结**

团队合作要综合考虑，能力、潜力和性格都是决定性因素，为大家创造一个和谐的工作环境，比什么都重要。

对团队成员要用心观察，有些不太正常的迹象时要及时引导。没事打打预防针，要比出问题了再解决成本要低得多，何况不是所有问题都能解决。

--------------------

### 资源分享 ###

**下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 `【保证100%免费】`**

![在这里插入图片描述][b9a9eea1ed5c42429c5e383b00ba6e0c.png_pic_center]

![在这里插入图片描述][d96b58a511f84668b59f3f620964da07.png_pic_center]

[b9a9eea1ed5c42429c5e383b00ba6e0c.png_pic_center]: https://img-blog.csdnimg.cn/b9a9eea1ed5c42429c5e383b00ba6e0c.png#pic_center
[d96b58a511f84668b59f3f620964da07.png_pic_center]: https://img-blog.csdnimg.cn/d96b58a511f84668b59f3f620964da07.png#pic_center