做为测试经理，这两年我都作错了哪些事

 

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

公司背景
近两年主要作项目外包。客户是央企，咱们作完的项目要过他们的测试部验收，测试超过两轮要罚款。他们经过的标准是通常问题不超过三个，轻微问题不超过五个。

第一次失败——冒进的左移
团队组建后，我等到了第一个全新的项目A。这个项目对我和个人团队来讲都是相当重要的，咱们须要这个项目来给本身树个标杆，开个好头。
因而我把过去两年我认为最有效的测试方案应用到项目-测试左移。在项目经理的配合下，咱们将项目按模块进行了拆分，并配合着制定了开发计划和测试计划，一切都有条不紊的进展着。随着项目的推动，一个致命的问题暴露了出来——返工。大量的工做被推翻重作，项目周期也延迟了一个多月。在这一个多月中，测试和开发团队都在不断的返工中度过。项目最后的交付质量也是惨淡收场——验收五轮。
项目结束后，我反思了失败的缘由：

1. 测试方案的激进： 在对项目的总体难度和项目团队能力有充分认知前，贸然的选择了最激进的左移，导致测试工做节奏混乱，在后期的不断返工过程当中，成员情绪也有很大的影响。
2. 里程碑拆分不科学： 在开发计划制定好以后，匹配测试计划时，单纯的只考虑了完成了哪些就测试哪些。彻底没有考虑到模块间耦合的问题，没有考虑后面开发和修改bug对已完成工做的影响，也是形成返工做主要缘由。
3. 变动失控： 这个项目的需求前先后后修订了几十版，一部分是客户频繁的提出新的要求，另外一部分是由于在项目进行过程当中本身发现的的坑，不得不一次一次的填坑。变动失控，势必形成无休止的返工和延期。
4. 低估了项目难度： 项目初期测试针对项目数据方面的逻辑设计了数据模型，可是随着项目的不断深刻，测试和开发达成的一致被不断的推翻，甚至在最后交付前，核心的数据逻辑测试和开发还发现有部分分歧。

错过了两次补救的机会

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

总结：

1. 全部的方案肯定都要依赖于对环境的充分了解和分析，每个项目都是独特的，盲目的套用会死的很惨；
2. 每个问题都不是个例，它背后必定有隐藏的缘由，深刻的挖掘问题才能避免更多的问题出现。

 

第二次失败——不灵活的“灵活”

团队组建之初，项目并行是咱们面临的一个巨大的考验。因而在项目B上，我尝试了团队的灵活切入切出，但愿实现人员的可插拔。
在项目B中，每一个阶段开发完成我都会尝试更换一名测试人员，但愿锻炼团队面对项目时的灵活性。项目B前先后后参与的测试人员有5名，最后的交付质量一样是五轮验收。
又是熟悉是场景，却有不一样的缘由：

1. 项目盲区： 人员变动势必形成对项目和需求的盲区，每一个人负责本身的阶段和模块，即便多作一些，仍然不足以覆盖到整个项目的盲区，盲区就Bug的温床；
2. 人人负责=没人负责： 当全部参与项目人都知道我只会在项目中工做一小段时间，当要求全部参与项目的人对项目负责的时候，就是没人会对项目负责；
3. 测试工做很失败： 在对客户验收的问题作总体分析以后，发现75%的问题是由于咱们对客户验收标准的不对齐致使的，如兼容性要求，需求文档要求，用户场景要求等，都被咱们忽略掉了。

总结：

1. 灵活可插拔，并不意味着全部人都须要频繁的变更，1+N的模式会更好。即一个负责人，加上N个可调整的测试人员；
2. 每一个项目有且只有一个负责人对项目负责，亘古不变的真理；
3. 对齐标准永远是第一要务，要芝麻给西瓜的事千万不能干。

第三次失败——成本才是王道

公司的项目所有都是功能测试，本着提高团队素质和产品质量的初衷，开始推动接口测试。在给团队作了两期的基础概念加工具使用的培训以后，找到项目经理选定了一个周期相对宽松的项目开始了接口测试之旅。过程总体符合预期，两周的时间完成了用例设计到测试的所有内容。发现了一些项目问题，团队也积累了实战经验。可是仍是失败了，此次失败不是这个项目失败了，而是接口测试没有推广下去。
这个缘由就显得更为冷酷了：
1. 成本压力： 接口测试的介入，并无减小功能测试的时间，增长的十几人天都是额外的成本。对项目质量的提高由于没有对比数据，因此没法体现；
2. 周期压力： 测试须要较完备的接口文档，才能支撑测试。理论上接口文档应该在项目设计阶段定义，但实际项目并无接口文档，swagger的信息也是简单的不能再简单了。开发人员须要额外的时间编写文档，测试人员须要额外的时间测试，客户又不会给足够的周期；

总结：

1. 扩充技能树是好事，可是目的应该是节省成本。任何不考虑成本的投入都是耍流氓；
2. 技能的应用应该更灵活，好比在里程碑中加入接口测试作验收，事半功倍。一味的放在集成测试中必然不会成功。

 

第四次失败——内部客户大于外部客户

有一天老板找到我，说有一个纯测试的项目须要评估一下。拿到信息以后作了基本的梳理，政务类项目，逻辑简单可是表单超级多，搬砖的活。将信息反馈给老板并与老板再次交流以后个人结论是-作不了，团队当时处于满负荷工做。后来与老板交流了几回，个人反馈都是作不了。最后老板找了几个在校的实习生来协助我，因而开始接触客户。在于客户的几回交流中，客户的诉求是但愿能节约成本，可是我仍是坚持质量第一位，最终客户接受了咱们的方案。项目最终顺利的作了下来，80多人天，900个bug，40000条用例，数据看还不错。为何也算成失败了？
1. 没有知足内部客户的诉求： 老板带过来的项目，可能有不少的考虑，好比利润，好比搭上新的客户等等。我在接收到信息以后，第一反应是个人团队消化不掉就不要作了，彻底没有考虑到要替老板攻下这个山头。
2. 没有知足外部客户的诉求： 在客户频繁的表达想下降成本的时候，没有站在用户的立场，可能政务类项目的质量标准和其余客户并不相同，可能这只是个演示版本，后期还会有更大的变更，种种可能都没有去过的考虑。虽然客户承认了咱们的方案，可是结果就是客户再也没有和咱们进行测试类的项目合做。
总结：

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 对团队成员要用心观察，有些不太正常的迹象时，要及时引导。没事打打预防针，要比出问题了在解决成本要低的多，况且不是全部问题都能解决。

 

待续······