测试周期的评估

如何评估项目的测试周期？任何一个测试部门的负责人都应该具备这样的能力，在现实的工作中，评估项目的测试周期其实是非常复杂的一件事情。

大家都知道，测试的过程其实并不简简单单是测试的事情，这个过程依然包含了开发的任务（BUG的解决），也就是说测试周期必须充分评估测试时间以及开发修复的时间。一个公司，如果开发团队的能力比较强，并且有非常好的流程保障的话，在一定程度上通常开发交付测试的项目的质量就比较高，而对于测试部来讲，可以按照1：1或者2：1的模式评估测试周期，然而现实的工作状态中，这是一种理想的状态，我相信很少有公司能保障这一理想模式。大部分情况基本都是“这个项目整个周期只有2个月，开发我需要40天或者更多”在这样的情况下，大部分公司采取的行为都是压缩测试的时间。虽然我们也非常清楚这样做是多么的不合理，可是除了无奈，我们似乎别无他法。也正式因为这样，对测试周期的评估就显得更加的困难，复杂了。

在我参与的很多项目中，项目启动初期，通常是各个部门“狮子大开口”的过程，只要开的不是那么离谱，通常都能得到保证，在这个过程中，测试部的要求也得到的很好的保证。随着项目的开展，需求的不断变更，可怕的事情开始，测试部虽然坚持，可是面对开发的“无米”状态，测试部也显得无能为力。

面对这样的现状，我在实际的工作中通常采用两套测试周期的评估方法。第一套就是按照1：1的方式评估测试周期，其实这套通常情况下是没有实际意义的，但这套评估方式能为测试部争取到一个主动的位置，如果可以的话，也可以为测试部争取更多的时间，在陈述为什么要这么多时间的时候，我们需要尽可能的把所有可能的情况都描述清楚，让项目小组觉得，测试的确是必须保证这么多的时间。当你占据这样一个有利位置的情况下，作为测试部的负责人，需要做一个事情就是测试周期底线的评估。这个过程是对测试时间，质量把控最好的一个方式。我们在第一套方案的基础上，把你认为可以提前的事情提前完成，把你在第一套方案中的“借口”划去，在这个基础上，重新制订一套测试周期评估方案，你对外争取到10天，实际你的心里底线是8天，当你在面对测试内部的人员时，你只能说是6天，这套方案实际是我们对内的方案，然而对于外界，当他们无奈中需要占用测试部的时间，压缩测试的时间时，由于他们已经理亏了，测试在后面的很多工作中能更加的顺利一些，而对于测试内部，你所有的安排其实没有被打乱，一切都依然在你的掌控中，一切进展都是那么的顺利！