SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?
2014-05-13 09:35
399 查看
开发人员奋斗了很多个夜晚,终于把版本提交测试了。他们可以松一口气了。但是噩耗很快传来,软件没有通过测试团队的预测试(为了保证测试进程,对开发人员提交的代码进行基本功能或业务流程的验证)。开发经理老王,迅速找到负责预测试的测试经理老张。
老王说:老张啊,怎么回事?出什么问题了?我们好不容易开发完成了,你们怎么不测试还把版本打回来了?
老张说:你们提交的版本质量太差,没有我们的预测试,需要重新修改后,符合我们的要求,我们才能测试。你看看我们发现的这两个问题。
老王并没有看这两个问题,而是直接质疑老张:听说你们最近测试环境搭建的有问题,是不是想借版本打回的时间再折腾一下你们的测试环境啊?可不能为了让我们开发的给你们打掩护啊!
测试团队经常会受到提交的版本质量太低的困扰。一旦开发团队提交的版本质量太低,测试过程中就会发现一些非常严重的问题而导致大量的测试用例被阻塞。而非常不幸的是,在项目发布时间不好更改的情况下,这样就会导致测试团队真正能够执行的测试时间被压缩,导致测试的任务无法及时保质的完成。打回版本在对测试团队造成影响的同时,也打乱了开发团队的进度。
于是有些团队就采用了预测试(有时候也称为冒烟测试)的方法,只有通过预测试的版本,测试团队才会开展正式的测试执行。上面的这个场景就是在开展预测试的时候,由于预测试失败而导致的冲突。
测试人员不仅仅是守门员,还应该在需要的时候主动出击。虽然设置预测试是一种提高测试接收的版本质量的一种方法,但是采用预测试的目的不是为了把版本打回去,毕竟回去了,还是要再回来的。测试人员除了被动的在等待开发团队提交版本过来以外,更应该积极的帮助开发人员,尽可能的是的他们能够通过预测试。有些项目中,测试团队积极主动的在测试执行之前帮助开发人员进行代码评审,也会帮助开发人员做部分的测试工作,这样就避免了被动等待。开发团队和测试团队良好互动,共同把项目做好。前期质量提高后,开发人员在测试人员执行测试期间,也可以有少量的开发人力来帮助测试团队。
入口准则在考虑开发因素的同时也应该考虑测试自身的因素。通常都是测试人员去检查开发人员的工作,但是测试人员自己的工作却常常没有得到充分的监督和检查。在制定入口准则的时候,除了对开发人员前阶段的活动的质量提出要求以外,对测试团队应该准备的条件也要进行约束,例如:测试环境的到位,测试用例的评审,自动化测试脚本的编写,测试数据的准备等。
具有可操作和可监控的客观的入口准则。入口准则虽然是针对测试活动的,但是不应该只由测试团队来进行,而应该在更广泛的范围内进行讨论,可以包括开发人员和项目经理等。同时为了符合测试出口准则而发生的活动,并不一定是由测试团队来执行的。例如:预测试可以由开发团队自己完成,而测试团队对测试结果进行检查。但是如果预测试的测试用例本身比较模糊,不同的人执行同样的测试用例可能产生不同的测试结果,那么会造成不必要的麻烦。
老王说:老张啊,怎么回事?出什么问题了?我们好不容易开发完成了,你们怎么不测试还把版本打回来了?
老张说:你们提交的版本质量太差,没有我们的预测试,需要重新修改后,符合我们的要求,我们才能测试。你看看我们发现的这两个问题。
老王并没有看这两个问题,而是直接质疑老张:听说你们最近测试环境搭建的有问题,是不是想借版本打回的时间再折腾一下你们的测试环境啊?可不能为了让我们开发的给你们打掩护啊!
测试团队经常会受到提交的版本质量太低的困扰。一旦开发团队提交的版本质量太低,测试过程中就会发现一些非常严重的问题而导致大量的测试用例被阻塞。而非常不幸的是,在项目发布时间不好更改的情况下,这样就会导致测试团队真正能够执行的测试时间被压缩,导致测试的任务无法及时保质的完成。打回版本在对测试团队造成影响的同时,也打乱了开发团队的进度。
于是有些团队就采用了预测试(有时候也称为冒烟测试)的方法,只有通过预测试的版本,测试团队才会开展正式的测试执行。上面的这个场景就是在开展预测试的时候,由于预测试失败而导致的冲突。
测试人员不仅仅是守门员,还应该在需要的时候主动出击。虽然设置预测试是一种提高测试接收的版本质量的一种方法,但是采用预测试的目的不是为了把版本打回去,毕竟回去了,还是要再回来的。测试人员除了被动的在等待开发团队提交版本过来以外,更应该积极的帮助开发人员,尽可能的是的他们能够通过预测试。有些项目中,测试团队积极主动的在测试执行之前帮助开发人员进行代码评审,也会帮助开发人员做部分的测试工作,这样就避免了被动等待。开发团队和测试团队良好互动,共同把项目做好。前期质量提高后,开发人员在测试人员执行测试期间,也可以有少量的开发人力来帮助测试团队。
入口准则在考虑开发因素的同时也应该考虑测试自身的因素。通常都是测试人员去检查开发人员的工作,但是测试人员自己的工作却常常没有得到充分的监督和检查。在制定入口准则的时候,除了对开发人员前阶段的活动的质量提出要求以外,对测试团队应该准备的条件也要进行约束,例如:测试环境的到位,测试用例的评审,自动化测试脚本的编写,测试数据的准备等。
具有可操作和可监控的客观的入口准则。入口准则虽然是针对测试活动的,但是不应该只由测试团队来进行,而应该在更广泛的范围内进行讨论,可以包括开发人员和项目经理等。同时为了符合测试出口准则而发生的活动,并不一定是由测试团队来执行的。例如:预测试可以由开发团队自己完成,而测试团队对测试结果进行检查。但是如果预测试的测试用例本身比较模糊,不同的人执行同样的测试用例可能产生不同的测试结果,那么会造成不必要的麻烦。
相关文章推荐
- SWTBOK测试实践系列(6) -- 开发人员为什么不做静态分析?
- 做一个开发人员认可的测试人员(系列3)--谈谈自动化测试框架
- 自动化测试开发实践系列(二)个人觉得测试开发应该学会拥有的
- 开发人员用的提交测试环境的AutoIT脚本
- SWTBOK测试实践系列(1) -- 测试在项目前期的评审投入划算吗?
- 做一个开发人员认可的测试人员(系列7)--外交家的能力
- SWTBOK测试实践系列(5) -- 项目中使用手动和自动化的策略
- 做一个开发人员认可的测试人员(系列5) ---也谈STAFF的应用
- “测试实践丛书”系列之“LoadRunner Vuser脚本开发”
- SWTBOK测试实践系列(8) -- 测试用例设计难在哪里?
- 做一个开发人员认可的测试人员(系列6)-如何使得机器的性能相当
- 测试开发人员需了解的基础算法系列(一)
- SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?
- 做一个开发人员认可的测试人员(系列4) ---也谈内存泄露
- SWTBOK测试实践系列(9) -- 设计的测试用例是否越详细越好?
- SWTBOK测试实践系列(4) -- 软件测试技术的黑白之道
- 应用Selenium + NUNIT对动态WEB测试自动化(自动化测试开发实践系列)
- iOS开发人员使用TestFlight构建测试版本
- ANDROID NDK实践开发系列(02)-- 在ndk跨版本使用surface显示输出
- 做一个开发人员认可的测试人员(系列1)--测试是技术活,没技术也能干