做为测试经理,这两年我都做错了哪些事(一)

「2020 新手必备 」极速入门 Retrofit + OkHttp 网络框架到实战,这一篇就够了!

 

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

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

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

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

错过了两次补救的机会

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

总结:

  1. 所有的方案确定都要依赖于对环境的充分了解和分析,每一个项目都是独特的,盲目的套用会死的很惨;
  2. 每一个问题都不是个例,它背后一定有隐藏的原因,深入的挖掘问题才能避免更多的问题出现。

 

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

集合类不安全之ArrayList

团队组建之初,项目并行是我们面临的一个巨大的考验。于是在项目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. 对待外部客户应该挖掘核心的诉求,满足客户才能带来长期的胜利。

待续······

Blazor 组件库 Blazui 开发第一弹【安装入门】

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享