软件测试中不需要测试的八件事

开发 项目管理
在我看来,我们提出的问题中和以上三个问题类似的还远远不够。可能这是因为我们已经被告知要测试一切东西。甚至我们的一部分人会在其质量团队中有一个流程,要求某个人把每一个组件都贴上“已测试”的标签。我们对待测试就像一个常规的工厂程序,我们甚至有时候引以自豪的说…

不要测试它

做为一名测试人员,我们也许会问我们自己很多问题:

  • 我们可以立即执行的***的测试是什么?
  • 我将要使用的测试方法是什么?
  • 这是一个 Bug 吗?
  • 我已经测试完成了吗?

但是我们之中会有多少人提出以下的这些问题呢?

  • 这个组件需要一直被测试到吗?
  • 需要由我来测试它吗?
  • 如果它不工作,谁会去在意它呢?

[[61603]]

 

在我看来,我们提出的问题中和以上三个问题类似的还远远不够。可能这是因为我们已经被告知要测试一切东西。甚至我们的一部分人会在其质量团队中有一个流程,要求某个人把每一个组件都贴上“已测试”的标签。我们对待测试就像一个常规的工厂程序,我们甚至有时候引以自豪的说…

“我是测试工程师。因此,所有的东西都需要被测试…由我来做…即使非测试人员已经测试过了…即使我已经知道它将会通过测试…即使需要一个程序员告诉我怎么去测试…我必须测试它,没有例外!”

这类想法可能会让测试人员有一个坏名声。由于欠缺思考的过程导致它强调了测试的重要性,而不是给一些人提供最有价值信息的服务。

James Bach 带着以下的测试观点出现:

基本的观点:“如果它存在,我就要去测试它”

正如前面内容和我经常发布的文章中,我不同意这个观点。尽管如此,我完全同意 James 在 2006 年 8 月 7 日,他在博客发布的完整版本中关于这部分的介绍:

“如果它存在,我就要去测试它(唯一的例外是我有更重要的事情要做)”

第二句话是可以有很多的理解方式!为什么呢?因为我们经常会有更重要的事情去做,通常是另外的测试工作!不幸的是,重要性往往不是区分的很明显。所以与其衡量重要性,我更喜欢提出上面的三个问题,去寻找那些可能不值得浪费我的时间去测试的东西。下面八个例子是我讨论的内容:

0. 不会在产品中出现的组件- 我的团队中在每次迭代中都有这些内容。例如增强功能中的错误记录表或者跟踪生产活动中的审查报告。在敏捷开发的团队中这些被归入开发者用户故事(Developer User Stories)。这些内容不会随便的在产品中出现并且由于其本质不会直接影响到用户。

1. 关键产品问题的补丁不会很糟糕 – 一天下午客户给我们的技术支持打电话,由于我们的产品的一个阻塞性质的 bug 导致他们处于错过一个关键***期限(DeadLine)的边缘。我们只有一个小时交付修复的产品。程序员很快的修复了问题,由于当前的产品是无效的,所以对修复之后进一步的产品存在的风险来说这是微不足道的。想要当英雄吗?不要让事情慢下来。快速的让产品通过测试。如果需要以后再去测试。

2. 界面问题修复要有适度的准备时间 – 我们修复了一个在屏幕上出现的用户错误消息中的拼写错误。用户并没有察觉到拼写错误但是我们无论如何修复了问题。很快而且简单。触发这个错误消息需要 30 分钟的准备时间,值得吗?

3. 直接了当的配置改变 – 去年我们产品开始偶尔出现很大的作业不能处理的问题。一个程序员尝试改变通用配置修复问题。但在 QA 的环境中没有一个简单的方法去创建一个足够大的作业超过这个临界值,很难去测试。我们在产品中修改了配置然后用户很高兴的为我们做了测试。

4. 技术性的需要非程序员的测试 – 测试部分功能时需要实施某种行为而在代码中设置断点来复现竞态条件.有时测试人员与工具和程序员精通产品代码的知识并不匹配。讨论这个测试但是回避它。

5. 非测试人员借用 – 如果团队中一个非测试人员帮忙去做测试工作,或者更重要的,想帮忙测试某一组件,让他去做吧。跟他分享测试的思路并且跟他要测试报告。如果你觉得满意,不需要再去测试它了。

6. 没有复现步骤- 程序员偶尔会尝试某些东西。经常会出现一些错误报告,但是没有人能对这些错误给出确切的重现步骤。我们也许想对修改的区域做回归测试,但是我们发布的时候不会阻止这种明显的修复,因为我们不知道它管不管用。

7. 不足的测试数据或硬件 – 让我们面对它吧。在我们 QA 的环境中,根据产品中所需要,大部分情况我们没有足够多负载平衡服务器。当一个有效的测试需要的资源在产品使用环境之外不可用时,我们可能无法对其进行测试。

很多人也许尝试想像上面这些如果不去测试会导致的问题。我也会做这些。记住,这些事情也许不值得花费我们的时间去测试。再次权衡你所做的事情,如果在不是很清楚的时候,去问问利益相关者。

如果你选择不去测试某些东西,很重要的是,不能被我误导。这是在我的团队中使用到方法。在我们进行组件审查时,我们的(测试人员)说,“我们将不会去测试这些”。如果有人反对,我们会改变我们的想法并且测试它。如果没有人反对,我们就“未经审查即批准(rubber stamping)”。即表明没有被测试就让它通过这样可以让他进入到最终产品。

所以下次你发现你自己正在着手做的测试,感觉比其他你应该做的事情更不重要时,你应该需要考虑…不去测试它。逐渐的,你的团队将会尊重你的决定并受益于更少的瓶颈,以及在你实际增加的价值的地方增长的覆盖率。

原文:Eric Jacobson

原文链接:http://blog.jobbole.com/15054/

【编辑推荐】

  1. 软件开发基本原则之***项目
  2. 聘用Node.js开发者的六个建议
  3. 软件开发如同木匠做桌子
  4. 网页开发的6种在线调试环境
  5. 基于引擎开发HTML 5游戏实战

 

责任编辑:林师授 来源: 伯乐在线
相关推荐

2012-08-23 09:50:07

测试测试人员软件测试

2009-03-06 19:17:21

Windows 7测试

2021-07-27 06:13:02

XDR厂商CISO

2021-08-03 10:40:47

混合云云计算应用程序

2014-04-10 09:45:50

移动应用测试iOS

2022-04-19 07:48:16

JavascriptCSS

2021-09-07 11:56:20

勒索软件攻击数据泄露

2013-07-09 10:04:16

SDN虚拟化

2019-09-11 15:29:08

工程师浏览器软件

2021-11-01 13:46:52

大数据嵌入式分析投资

2011-05-19 16:47:50

软件测试

2017-10-22 16:01:25

Ubuntu系统浏览器

2021-06-11 10:03:34

数据泄露网络安全网络攻击

2023-10-16 13:36:00

边缘计算数据

2020-12-31 23:38:33

AIOpsIT运营

2013-03-04 13:28:39

ITSaaS云计算

2011-04-12 09:48:03

2013-12-18 09:49:11

Windows 8.1SkyDrive

2023-10-17 12:51:00

边缘计算云计算

2023-02-08 15:49:34

Linux系统
点赞
收藏

51CTO技术栈公众号