51Testing软件测试论坛

标题: 做为一名测试经理，这2年我都做错了哪些事 [打印本页]

作者: lsekfe 时间: 2023-12-21 14:29
标题: 做为一名测试经理，这2年我都做错了哪些事
我是一名测试经理，在过去的两年时间做了两件事，团队从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. 没有满足外部客户的诉求：在客户频繁的表达想降低成本的时候，没有站在用户的立场，可能政务类项目的质量标准和其他客户并不相同，可能这只是个演示版本，后期还会有更大的变动，种种可能都没有去过的考虑。虽然客户认可了我们的方案，但是结果就是客户再也没有和我们进行测试类的项目合作。
　　总结：
　　对待内部客户应该像是对待家人，解决他们的问题应该是放在第一位考虑的事。就像孩子过来跟你说我饿了，你的第一反应应该是我要想办法给你弄点吃的，而不是我没有钱。　　对待外部客户应该挖掘核心的诉求，满足客户才能带来长期的胜利。

第五次失败——裁员风波
　　这是个敏感话题，对我产生了比较深远的影响。团队有一个小姑娘，在公司的一年中整体变现平平，且呈现了较明显的下滑趋势。有三个问题让我开始认真考虑：
1.与团队合作的时候经常发生争吵。有一次他们两个人在针对一个测试点交流的时候，另一位同事问她，这个有没有测过，小姑娘在办公室就急眼了，意思是你不信任我就自己干吧；
2.工作时间总是玩手机，消极怠工，负面情绪对团队产生了比较大的影响；
3.bug产量持续垫底，我对比了她参与的全部项目，bug数量都是最少的，且差距非常大。在持续观察了一段时间之后，综合考量了产出，贡献，资质，成长空间和对团队带来的影响等方面，最终决定做辞退处理。由综合部门出面处理了这件事情（协商处理，没有发生法律风险）。
　　这件事又为什么定义成失败，主要两方面的原因：
　　1. 没有对综合部门做到足够的支撑：在做出辞退决定是，并没有第一时间给与综合部门足够的数据支撑，最终可拿出的数据维度也相对单一，为综合部门面谈造成了不小的困难；
　　2. 没有及时反馈：在团队成员出现问题的时候，没有在第一时间做出反馈，或者在反馈几次之后丧失了对成员的信息，导致情况发展到了一个大家都不太原因看到的局面；
　　总结：
　　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. 对团队观察不够细心：没有从平时的交流中发觉端倪，当问题明显化之后，再想弥补就几乎不可能了。
　　总结：
　　1.团队合作，要综合考虑，能力、潜力和性格都是决定性因素，为大家创造一个和谐的工作环境，比什么都重要；
　　2.对团队成员要用心观察，有些不太正常的迹象时，要及时引导。没事打打预防针，要比出问题了在解决成本要低的多，何况不是所有问题都能解决。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)