一篇文章讲清楚如何对软件缺陷进行管理(3)

代价太大

正规的软件公司会引入QA，对项目整个过程进行全方位的质量保证工作。但是执行QA需要调用很多的资源，比如要检查和复审需求阶段输出的标准工件，就需要高水平的分析员加入，但是通常他们时间很少很宝贵，并且不会有太多的精力顾及此事。

在设计和实现阶段，随着大量审查工作的介入，所有该阶段的参与人员都要付出更多的时间和精力来参与。

这些形式的检查、审查和测试延长了整个项目的开发过程，这些附加的工作时间都会直接变成附加费用，大大增加了整个项目的造价。

市场决策

即使测试人员发现了产品中的BUG，但是公司会觉得修复BUG将延长整个产品的发布时间，有可能错过销售的旺季（可能是每年的5-10月份），并且会打乱整个公司针对该产品的销售计划，在确认产品中的BUG不是非常严重的情况下，软件被销售了。但是，如果这是航天、医疗、股票交易的管控软件系统，如带有BUG，则发布后果是非常严重的，但是对于某些行业这样的做法是可行的。

时间紧迫

测试要花费大量的时间，至今尚未有一种自动化的测试工具能够全面和高效率地测试一套软件产品。

测试项目经理接到测试任务后表现得过于乐观，没有考虑任务的风险。

开发人员过高估计自己的能力，认为所有的BUG都是微不足道、便于修复的。他让测试工作和编码工作同时进行，这样根本没办法保证测试的正确性。并且在时间紧迫的时候，大多数测试员只是选择明显的几条程序路径测试或者输入不完整的测试数据，这些都造成了大量的BUG纰漏。

现场证据

有时会遇到这种问题，发现了BUG但是不知道怎么把它明显地表示出来。不能向开发人员提供足够的证据报告，是测试人员的耻辱，开发人员同样会根据这样的报告讥笑测试人员的所作所为。

BUG的可重现性，与导致BUG出现的原因有着密切的联系。

BUG的可重现性也体现了测试人员对软件系统的熟悉程度。

BUG的可重现性，也体现在操作的顺序上。

过于自信

开发人员是非常不诚恳的测试人员，他们总是说“我做的肯定没问题”或者“不可能呀，它在我的机器上跑得好好的”。有的时候项目管理者也很自负，过于相信团队成员的表现，而不去理会测试人员或者客户的抱怨。

Titanic灾难就充分体现了人类的自信，我们有足够的水密舱就算破了5个船也不会沉。

没有详细的测试计划，没有严谨的测试行为，不再关注每个细小的环节，这样BUG就从旁边悄悄溜走了。

原文转自：http://www.uml.org.cn/Test/201611161.asp