不要测试它
做为一名测试人员,我们也许会问我们自己很多问题:
● 我们可以立即执行的最好的测试是什么?
● 我将要使用的测试方法是什么?
● 这是一个Bug吗?
● 我已经测试完成了吗?
但是我们之中会有多少人提出以下的这些问题呢?
● 这个组件需要一直被测试到吗?
● 需要由我来测试它吗?
● 如果它不工作,谁会去在意它呢?
在我看来,我们提出的问题中和以上三个问题类似的还远远不够。可能这是因为我们已经被告知要测试一切东西。甚至我们的一部分人会在其质量团队中有一个流程,要求某个人把每一个组件都贴上“已测试”的标签。我们对待测试就像一个常规的工厂程序,我们甚至有时候引以自豪的说…
“我是测试工程师。因此,所有的东西都需要被测试…由我来做…即使非测试人员已经测试过了…即使我已经知道它将会通过测试…即使需要一个程序员告诉我怎么去测试…我必须测试它,没有例外!”
这类想法可能会让测试人员有一个坏名声。由于欠缺思考的过程导致它强调了测试的重要性,而不是给一些人提供最有价值信息的服务。
James Bach 带着以下的测试观点出现:
基本的观点:“如果它存在,我就要去测试它”
正如前面内容和我经常发布的文章中,我不同意这个观点。尽管如此,我完全同意James 在2006年8月7日,他在博客发布的完整版本中关于这部分的介绍:
“如果它存在,我就要去测试它(唯一的例外是我有更重要的事情要做)”
第二句话是可以有很多的理解方式!为什么呢?因为我们经常会有更重要的事情去做,通常是另外的测试工作!不幸的是,重要性往往不是区分的很明显。所以与其衡量重要性,我更喜欢提出上面的三个问题,去寻找那些可能不值得浪费我的时间去测试的东西。下面八个例子是我讨论的内容:
1、不会在产品中出现的组件- 我的团队中在每次迭代中都有这些内容。例如增强功能中的错误记录表或者跟踪生产活动中的审查报告。在敏捷开发的团队中这些被归入开发者用户故事(Developer User Stories)。这些内容不会随便的在产品中出现并且由于其本质不会直接影响到用户。
2、关键产品问题的补丁不会很糟糕– 一天下午客户给我们的技术支持打电话,由于我们的产品的一个阻塞性质的bug导致他们处于错过一个关键最后期限(DeadLine)的边缘。我们只有一个小时交付修复的产品。程序员很快的修复了问题,由于当前的产品是无效的,所以对修复之后进一步的产品存在的风险来说这是微不足道的。想要当英雄吗?不要让事情慢下来。快速的让产品通过测试。如果需要以后再去测试。