负担累赘

如果您的 QA 团队已经在一起一段时间了，并且如果在测试中已经很有效，那么必须建立相当多的自动化测试和运行测试的框架。但是可能有许多测试的生命长过其有效时期。随着越来越多的测试被撰写出来，团队可能必须拿出不断增加的时间量来维护测试及其框架。

我近见到一个在一家非常成功的软件公司工作的人，该公司中的 QA 团队有这样的问题。经过十多年的工作，他们已经创建了差不多数千个自动测试。实际上，他们有许多测试，要运行所有的测试几乎要花上一整天。在这些年内，如此多的人写了那么多的测试，没有人清楚所有这些测试所测的是什么。

这是测试自动化的负担。在那些时候，每个测试都是出于很好的理由而撰写的。但是随着时间的过去，每个测试的理论根据已经失去了。而且，将这些测试组织为多种、但仍旧非常大的测试组。结果是，甚至是单个的测试组都要花几个小时来运行。团队总是为产品中新的或修改了的特性撰写新的测试。要更加高效，他们需要“ 减少不再提供价值的测试组”。

您如何使测试更加高效？少测试。跳过那些不能充分证明还有效果的测试。集中于撰写和运行更重要的测试。换句话说，撰写并运行那些将找到新的更严重的缺陷的测试。

OK。这听起来很容易。但是您如何确定哪个测试是足够重要的，以至于对它们运行并维护？这全部依赖于您的产品中危险的部分。换句话说，现今谁危险。

了解产品的风险以及总是调整风险变更的需要。

有时候，因为是新增的或者因为遭受了变更，代码处于危险之中。Myers（在 Art of Software Testing ?? 仍旧是我所看到的好的软件测试书籍），1 谈论了一般在已经改正了老的缺陷的区域上如何找到新的缺陷。这可能因许多原因而出现 ?? 也许因为代码是多缺陷的，设计是不完善的，或者因为它经常变更，并且问题常常出现在原始代码没什么问题的时候，而是因为正在增加新的特性。

随着新特性变老，这种级别的风险会随着时间而变更。如果代码没有随着时间而变更，不论是由于缺陷或是增强，与其他代码相关的风险级别可能降低。因此总是知道当前的情况并调整计划，处理处于风险中的部分是很重要的。您的资源总是有限的，但是可能的测试数量总是无限的。

有时候，风险级别与代码的“健康”无关，但是因为正在讨论的特性（或配置）一般对产品或具体的客户来说是关键的。我曾经在一家网络公司工作过，该公司将一个产品进行了 beta 测试，尽管用某一种类型的调制解调器会失败。发生了什么？您猜猜，第一个测试版的用户使用了那个类型的调制解调器。

除了了解处于风险中的部分以外，您还必须不断调整您的计划以匹配软件变化的状态。作为媒介的软件是有延展性的，2 以至于很容易快速进行根本的变更，并且与此同时很快引入新的风险。您试图提前预料每一件事，但是在测试期间，您总是了解到一些新的内容，并且不得不改变计划，结合新的或变更的（或删除的）测试。

总结

使得效率低的团队高效起来是很难的。

如果您想确定您的团队在哪里，如何效率低，那么不要欺骗自己。对时间花费在哪里，及如何花费的进行关键性的审阅。接受您某天将不得不把一些测试抛弃的事实。

对于QA团队来说什么是高效的？既是他们能快速地找到严重的缺陷。

为了更高效，并找出那些严重的缺陷，着重于处于危险中的内容。

记住处于危险中的事物总是变化的，您不得不适应且保持适应。