当我们谈质量时,我们在谈什么?

five3five3 34 于 2019-06-22 22:09:05 发布
  • 11 推荐
  • 0 收藏,22 浏览

当我们谈质量时,我们在谈什么?

今天“不幸”被老板拉去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 Web自动化测试设计与实现

获取更多关于Python和自动化测试的文章,请扫描如下二维码! 关注二维码

你可能感兴趣的文章

本文隶属于专栏

TestQA @ TestQA

TestQA's Blog