加V:19841731,领 MTSC 大会历届 PPT

【原创】Google 软件测试流程中的致命缺陷

上一篇 / 下一篇  2019-05-08 12:51:59 / 个人分类:测试基础

前面我已经写了三篇关于《Google 软件测试之道》的荐读和读书笔记,这是我读完一本书之后写读书笔记最多的一次了,主要是因为他引发了我太多的思考,也开拓了我对于测试未来的想象。

前三篇可以点击链接查看:
Google 软件测试之道
Google 软件测试之角色职责
Google 软件测试的未来

今天是这个系列的第四篇,仍然是关于书中第五章的内容解读。

第五章中 James 除了阐述 Google 软件测试的未来之外,还着重提到了 Google 流程中的致命缺陷,里面有一些和我们目前的情况十分相似,另一些则警示我们要提前注意可能出现的问题。

下面我会针对这些缺陷,逐个进行说明。

缺陷一:测试成了开发的拐杖。

本来质量是所有人的事,但是因为有了测试部门的存在,开发人员越来越少的考虑质量问题,越来越不会去测试,因为他们认为质量是测试人员的责任。

关于这点,应该是有共识的,有反馈找测试,漏出 bug 找测试,所有问题都可以归结为一个终极问题「为啥测试没有测出来?」

如果继续目前的做法,这个问题是没法得到解决的,但是可以借助之前「测试即服务」的方法间接解决。

我们服务于产品,在需求阶段解决需求问题。
我们服务于开发,在编码阶段解决架构和技术实现的问题。
我们服务于用户,从用户角度解决体验性问题。
我们服务于质量,深层次挖掘逻辑问题。

缺陷二:开发和测试的隔离,阻碍了测试人员对产品的关注。

James 要表达的是 Google 独立的测试部门,导致他们更注重测试工作本身的事情,从而忽略了我们是为业务服务的大目标。

这个在国内目前的环境,基本不是问题,甚至部分公司会出现测试过于依赖业务,进而失去了自己作为测试应该具有的独特视角,仅仅成为一个工具。

我理解只要记住两点就够了:

测试是为保障质量服务的;
质量保证是为业务目标服务的;

缺陷三:测试人员往往过于崇拜测试产物。

这点主要强调的还是测试太过于关注测试本身,比如测试流程、计划、用例、工具、系统、bug 等等,所有这些都是测试过程的产物,所有这些产出的目标都应该是为了保证产品质量。

这其实牵涉到另一个比较大的话题「如何进行软件测试人员的绩效考核」,考核目标不一样,对应的就是大家的关注点的不一样,所以这个方面每个公司根据自己现状不同,都是有一些差异。

总体来说,James 表达的这个意思是没问题的,确实业务是最终的目标,测试人员应该把产品放在第一位,目前剩下的就是怎么去制定合理的考核指标,让我们的目标和业务目标能够保持一致。

缺陷四:产品经过测试后并仍然会遗漏问题。

这点确实没法完全保证,James 指出的原因是 TE 只是想象自己是用户,而试用者是真实的用户,所以才会漏出问题。

从我的经验看,其实可以分为两种情况考虑。

一种是功能问题的漏出,比如逻辑分支缺少用例覆盖。

这种肯定就是测试人员的问题了,有可能是需求没有搞透彻,有可能是实现逻辑没有弄清楚,有可能是自己用例设计的方法不熟练,解决办法当然是对症下药。

另一种是用户场景的遗漏,比如真实用户使用产品的操作方式没有覆盖到。

这种情况,产品、开发、测试和运营部门都是应该参与试用的,特别是作为产品的第一批用户,我们应该在我们的生活场景中去使用我们的产品,而不仅仅是想象我们的角色,一定要作为真正的真实用户去使用产品。

当然,内部试用、灰度发布和快速迭代也可以解决这个问题,但是这时候漏出的问题应该是符合预期的,因为本来就是期望他们来发现这些体验性问题。

以上,James 提到的 Google 流程中的缺陷在你当前流程中是否存在同样的问题?目前是怎么解决的?是否有更好的解决方案?欢迎留言说出你的想法。

当然,如果你觉得我上面的内容对你有启发,请帮忙转发 + 点个「赞」让更多人看到,谢谢。


TAG: 软件测试 Google

引用 删除 ITgiant   /   2020-03-05 19:24:50
3
 

评分:0

我来说两句

sylan215

sylan215

加V「19841731」,领 MTSC 大会历届 PPT。

日历

« 2024-03-27  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 109124
  • 日志数: 91
  • 图片数: 1
  • 建立时间: 2018-07-03
  • 更新时间: 2021-11-11

RSS订阅

Open Toolbar