在没有确定测试边界的情况下评估测试完成时间
测试什么时候算完成呢？两天，三天？所指的完成是所有测试项都完成了？如兼容性测试，性能测试，安全测试，易用性测，安装卸载测试，等等。随着列出这一系列的测试项，如果在评估测试完成时间没有考虑过，有没有直冒冷汗？我们在评估测试完成时间时，一定要确定测试的边界，测试完成指标，否则当交付用户使用时，出现问题，可能就要被问责了——为什么在测试时没有考虑到这些问题？不是说测试完成了吗？
通过测试，发现了所有问题
当编写报告或向领导汇报时，说已经发现了所有问题？真的是这样吗？我们都知道零缺陷几乎就是一种不可达到的理想情况。所以，我们在编写报告或汇报时，应该说目前从根据执行现有的用例来看，没有发现更多bug。这不是担当问题，而是一种工作态度的严谨。否则错误的传递信息，可能使领导和客户建立盲目的自信。最后出现问题时，往往会变得非常懊恼，把所有的责任都归咎于测试团队头上。毕竟你们说的是没有问题了。
通过测试能保证产品质量
在我面试过程中，有相当部分的面试人员都错误的认为通过测试能保证产品的质量。实际的情况是，通过测试既不能提高产品的质量，也不能保证产品的质量。产品质量更多在于最初的设计，构建产品的人，然后需要整个团队去保证最终的质量。保证质量是一个沉重的负担，需要整个团队认识自己对产品质量的责任。否则，把质量保证丢给测试人员，那对测试团队来说是不能承担的责任。
测试对产品发布具有一票否决权
测试团队是产品的守门人，只要测试团队不允许产品发布，那就不能发布。如果真是上面这样，那这将是一个糟糕的情况。如果测试拥有产品发布否决权，是否要面临发布延期导致的责任。当产品上线后，出现问题需要担负主要责任，谁让交付的产品有问题来着。所以我们最好把产品是否发布由具体表决决定，或者让项目经理根据收集到的情况做决定。在大多优秀高效的项目团队，往往产品是否发布都是采用某一种方式，大家集体决定。
指望项目中每个角色都能理解测试
程序员或者项目经理如果都能理解测试，支持和帮助测试团队，那再好不过了。但大多情况下，程序员、项目经理是不怎么了解测试的。比如测试需要获得哪些支持，如果测试人员不主动提及，是很难让让他人知晓的。更有可能项目决策人对测试一知半解，提出一些不能完成的目标，如果测试团队不去澄清和解释，可能就会导致上下互相抱怨，从而使团队氛围变得糟糕。所以我们测试人员有责任，在吃饭时间(在不正式的场合下)向相关人员阐明软件测试的概念，如何开展测试及团队的使命等。
测试书中的定义就是金规铁律
测试书中是这么说的，所以我们就应该这样做。测试做到越后，越清楚测试还没有太多明确的定论。如果我们事事都按书中所说去实践测试，那可能会导致各种各样的问题。就如软件测试就是为了发现bug执行程序的过程，软件测试就是为了让项目团队建立信心。单个来说都有争议，但实际这两种观点可以从两个纬度去说明为什么做测试。我们测试不能仅做一个复制者，更应该做些创造性的事情，这样才能走向精深。测试没有定论，应该看我们自己。