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

本文分析了Google软件测试流程中的四个致命缺陷:测试成为开发的拐杖,开发与测试隔离,测试人员过度关注测试产物,以及测试后仍会遗漏问题。作者提出了解决这些问题的思路,强调测试应服务于产品、开发和质量,并探讨了如何避免测试与业务目标脱节。
摘要由CSDN通过智能技术生成

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

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

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

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

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

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

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

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

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

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

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

James 要表达的是 Google 独立

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值