这是在测试工作中最需要明确的,也是非常多的项目忽略的工作。在做测试工作之前,一定要非常明确准备对那些内容进行测试,预计达到的质量标准是什么,尤其是对那些不进行测试。
我遇到过的很多的测试经理都抱怨说:“我们不可能在前期把这些事情都弄清楚,开发人员都不知道产品将来是什么样子,我们怎么知道需要测试那些内容?”咋一听,感觉很有道理,但是情况是否真像大家说的那样?作为公司,或者项目经理都希望能将项目做好,能生产出一件令用户满意的产品,如果这个假设成立的话,这也就是我们能够改变现状的动力。
首先,原先的那种做法已经多次证明是行不通的,所以只有改变我们的做法才有可能成功,前期先弄明白我们打算做什么并不是一个过分的要求。
其次,开发人员实际上并不是完全不知道他们打算生产什么样的产品,而是就一些细节考虑的不够,或者不周全。作为测试人员,一定要知道如何对一件产品的功能和性能怎么验证,这实际上在帮助开发人员从使用者的角度上重新的审视一遍需求,也许这时候开发人员也说不清楚,那如果你和开发人员都非常清楚那些是明确的、那些是需要后面再补充的,也已经达到了我们的目的。
被测系统有无明确的性能指标?
对性能要求比较高的系统,需要在前期明确具体指标到底是多少?用何种手段进行确认?用户是否认可这个指标的描述以及确认的方法。
性能指标一般从需求中对一些敏感的数字的描述中来,如:必须保证能处理30个在线用户同时操作,主要业务系统响应时间不能大于1.5秒等。
针对这些数据,测试人员一定要细化数据背后的含义,使这些数据变得可验证。如在规划这些性能指标的验证方式时,首先需要明确软硬件的环境是什么?在此基础上,还需知道什么叫30个在线用户同时操作?都操作什么?这个场景应该怎么模拟?只有和这个指标相关的所有验证方法都可行,而且得到了认可,在后续的测试活动中我们才能相信这条性能指标能够进行测试。
测试工作有无明确的阶段划分(如单元、集成、系统、验收等)?各阶段是否有明确的交付确认条件?
实际过程中,我们都会将测试工作按照阶段进行划分,上面描述的是一个通常的划分方式。在做监控工作时,还需要明确一点:这些阶段的划分是不是只有时间点的描述,而没有各个阶段之间可量化、可衡量的交付确认条件?
如果只有时间点的划分,那我已经可以断定,这个项目势必会延期,原因是在整个生产活动过程中没有明确的阶段点交付的检验标准,问题肯定会沿着整个开发过程逐步的传递下去,终归会在某一点爆发,最不幸的爆发点是在客户处。
如果想尽量的避免上述的风险,就需要在开发过程中明确各个阶段点之间的交付、确认条件。而且这些条件必须可量化、可衡量,决不能是含糊的,不易操作的,否则在实际操作过程中还是会将大量的问题推入下一个阶段。