测试管理 当我们谈质量时,我们在谈什么?

上帝De助手 · July 17, 2019 · Last by 上帝De助手 replied at July 22, 2019 · 2458 hits

今天“不幸”被老板拉去REVIEW刚结项的项目,结果自然是一顿被批评;不过从总体“收益”来讲还是比较“划算”的!毕竟还是学习到了很多东西,其实我还是比较喜欢这样的REVIEW,因为它可以给自己带来较快的成长!

既然说到了被REVIEW、被批评,那么今天要说的内容自然就是与这个相关的。在此之前我们可以问自己几个问题:

  1. 作为测试人员,我们该如何保证质量?
  2. 作为项目OWNER,该如何保证质量?
  3. 作为一个大型项目的OWNER,该如何保证质量?
  4. 作为一个大型紧急项目的OWNER,该如何保证质量?
  5. 作为一个大型紧急新接手项目的OWNER,该如何保证质量?

我相信,很多时候这些问题就可能出现在面试当中,尤其是非技术流,偏项目管理的岗位面试中。虽然说我是偏技术流的,但也避免不了被问到这样的问题,甚至我在面试别人的时候也会问到这样的“奇怪”问题。

无形的“被动”

作为测试人员,我们经常会发现自己的工作非常的“被动”。比如:被动的等着开发提测的延期;被动的背起线上的bug;被动的要保证100%的项目质量(即使开发一点自测都不做)。

如果你“摸”胸而论,你还会觉得这些都是作为测试应该有的结果么?来自你内心深处的答案肯定是否定的,当这些事情被摆在明面上的时候,很多人都会“情不自禁”的接受了!

为什么会这么被动?是因为我们从根本上没有明确测试的职责!我们不是应该是被延期的对象,不应该是背锅侠,更不应该是保障质量的唯一能力者。

开发自测VS测试人员测试

前几天看到一篇文章写的很好,讲的就是开发自测与测试人员测试的本质区别,并且我还转发到朋友圈了。文章中打了个比方来形容两者的区别。

如果说质量是一张平面,平面中有一个圆圈,开发自测就是等于在圆内做检查,而测试人员的测试则是在圆外做检查。即一个是在既定/有限的区域内保障质量,一个是在未知/无限的区域中探索质量问题。

所以你就能理解,为什么需要开发做单元测试、需要TDD、需要自测,因为这本来就是他的本质工作。如果一个开发人员写完一个功能后,自己都没有完全跑通就提交测试,那么肯定是一个不合格的开发人员,是需要慎重对待的。

同样你也能理解,为什么开发自测了,测试人员还有需要存在的价值。测试不仅是开发的DOUBLE CHECK,更是对未知区域隐藏bug的探索,也是对非功能性需求的覆盖测试。

不存在的“完美”质量

测试人员的思想往往会被带入常识性的误区。比如:作为专业的测试人员不应该有bug;只要是质量问题就是测试的锅。其实这些都是不对的,只有没被发现的bug,没有0bug;所以我们不需要追求100%的质量,这个是不存在的。天塌下来还有“高个子”顶着,项目出了质量问题,第一责任人首先应该是最高负责人。

所以有bug或者有缺陷的项目是可以接受或者上线的,但前提一定是这些已知/未知缺陷是在当前可接受范围内。比如:线上大促,肯定不能是性能有问题;参加大赛,肯定不能是流程中断问题。

如果说测试也遵循着2/8原则,花20%的精力就能发现80%的bug,那么我肯定不会把剩下的80%的精力再去发现剩下的20%的问题。首先产出比不高,更重要的是它存在很大的风险。所以剩下的80%的精力一定是思考如何更好的保证正常功能的稳定性,思考各种极端环境可能出现的问题及其对应的预备方案。而剩下的20%的问题则属于长尾问题,需要长期不断的优化和打磨,可能即使你“毕其一生”也发现不完!

技术保障“质量”

严格来讲,技术保障质量是个伪命题。因为研发/测试人员本身都保障不了质量,技术又怎么能保障质量呢?当然这并不妨碍我们在质量保障过程中使用技术手段,毕竟技术可以提高测试效率、增加测试覆盖率、增强测试手段。所以技术在质量保障过程中还是有它独特的价值的,并且不同项目中体现的价值也会有差异。

技术保障适用于那些测试场景重复且固定流程的改进,适合那些机械且重复组合的场景;技术保障适用于我们平常没有时间或者覆盖不到的场景,比如:单元测试、API测试;技术保障适用于那些手工无法测试的场景,比如:建造大量的测试数据,控制程序的微观操作,测试场景的改造和测试内容的欺骗。

技术保障的方式有很多种,在不同的团队和项目组中达到的效果也不尽相同;在应用好的项目中它是利器,在应用不好的项目中它就成为了鸡肋。因此还考虑使用技术来保障质量的之前,需要深刻思考它真正能解决的问题和期望能达到的效果,甚至可以先使用DEMO来进行一段时间的适用,在拿到实际数据之后再评估是否真的需要技术改造。

什么是质量

质量从来都不是测试说了算,也不是老板说了算,而是用户说了算。你认为不是问题的问题,对于用户可能是不可接受的bug;而你认为是问题的问题,对于用户可能根本就是不是问题;你认为不会出现的问题,在用户那可能就会真实的出现。

质量可以是项目/产品的验收标准,包括功能性、非功能性的;同时质量也是用户的一种综合体验,越多的人觉得系统/产品好用,就说明质量越高。而那些小部分人认为不习惯用,和用户不关注的bug都应当不在质量的范畴之内!

质量不是说线上一定不能出bug,质量是长期稳定的保障服务正常运行,保障用户体验流畅,保障用户留存率,保障业务收入的一种能力。不影响这种能力的线上bug,可以视为低价值的bug;这类bug不是不改,而是应该在合适的时间里去修复它。比如:项目组有额外精力的时候。

质量是一种自顶向下的态度,为什么微软、谷歌的项目质量做的比较好?那是因为它们是技术性公司,从顶层设计时就会考虑质量,不仅仅只是考虑功能的开发;所以一个完整的项目/系统设计,一定是从一开始就确定了如何去度量质量,如何去执行测试,如何去覆盖场景,如何协调团队的整体资源分工合作。

如果把测试当做足球守门员,那么开发就是后卫,项目管理者就是中场,高层领导就是前锋。虽然位置不同但是目标是一致的,质量保障就像防守一样需要整个团队的通力合作才能做到更好。如果所有问题都直接漏到测试这一层,那么“守门员”就会被打成筛子,即便他使出了“洪荒之力”。

质量体现在可控的流程之下,有些人可能会觉得有些系统就是没有质量问题;比如:银行系统为什么不出错,航天系统为什么不出错。实际情况真的是这样么?当然不是。新闻偶尔也会爆出ATM机可以取出超额的现金,电影里也会演绎利息余数的bug,NASA也有发射失败卫星失败的时候,导弹也会有击中错误目标的情况,甚至某飞机近期接二连三的爆出飞行事故问题。

但是当我们反过来思考的时候,你会发现虽然这些系统也会有一些意外的情况,但是它们发生的概率还是非常小的,一旦发生就会是新闻级的现象。而之所以这些系统的质量在普通人眼里觉得非常高,根本原因是在于这些系统都是固定的流程系统,每一个操作、指令、设备都是有严格要求的,不是你想怎么操作就怎么操作的。而我们日常所测试的系统则是用户产品,所以你懂的!

当我们在谈“质量”时

  • 是保障80%,还是追求100%
  • 是追求0BUG,还是追求不出错
  • 是测试来背锅,还是领导来负责
  • 质量属于测试,还是质量属于团队
  • 质量是常规功能,还是用户综合感受
  • 质量是穷举未知范围,还是确定固定流程

欢迎大家讨论交流,另外获取更多关于Python和自动化测试的文章,请扫描如下二维码!

共收到 19 条回复 时间 点赞

好文,顶起

深度好文,赞,可能很多人都明白的道理,但是都没有去反思,质量依赖于团队,测试要把质量管理起来!

赞,质量是贯穿项目的整个生命周期,还是质量意识不够

这篇文章真的很棒!

学习了!“从顶层设计时就会考虑质量,不仅仅只是考虑功能的开发”!我们公司发现bug,都是测试在背锅!😭

赞,但是做起来比说起来难多了

写的真好,讲出的国内测试的一个通病,希望能有更多的人看到~

质量太好,QA没饭碗了;质量太差,QA累死了。兴,百姓苦;亡,百姓亦苦。王侯将相宁有种乎!😂

张全蛋 回复

开发也一样啊。

名言:

  1. 代码写得好,bug少,看起来像一个闲人
  2. 注释多,解耦好,代码清晰,任何人都可以替代。
  3. 代码写的烂,每天风风火火改bug,各种救火,解决线上各种大问题,于是顺利成章成为公司不可替代的人才。
  4. 代码乱只有自己看得懂,是公司不可替代的人才
cmlanche 回复

至理名言。哈哈,不过这个也看公司氛围、领导者怎么看待和提拔人吧。

wtnhz 回复

是的,实践起来真的会比较难。要么现有团队有这个基因。或者新打造的小团队从开始就抓起。

张全蛋 回复

其实质量更多的是团队的担当,不应该过分跟QA挂钩。如果一个团队的QA比开发都多,那到底是好还是坏呢。

深度好文!

多谢各位支持,有需要的话鼓励转发,保留出处即可_^

感同身受。👏

cmlanche 回复

不是的,质量其中之一是建立度量,说白了就是公司质量体系,会侧面反应出一个开发的能力,如果没有的话,开发主管也能体会出来。

萝卜 回复

有道理

质量就是在没有人监督的情况下把事情做正确

19Floor has been deleted

赞!就是潜意识的!

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up