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

标签：推广   工具使用   和我   了解   重要   坚持   结果   信息   通过   

我是一名测试经理，在过去的两年时间做了两件事，团队从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. 对待外部客户应该挖掘核心的诉求，满足客户才能带来长期的胜利。

待续······

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

标签：推广   工具使用   和我   了解   重要   坚持   结果   信息   通过   

原文地址：https://www.cnblogs.com/lunerz/p/12095919.html