SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?

开发人员奋斗了很多个夜晚,终于把版本提交测试了。他们可以松一口气了。但是噩耗很快传来,软件没有通过测试团队的预测试(为了保证测试进程,对开发人员提交的代码进行基本功能或业务流程的验证)。开发经理老王,迅速找到负责预测试的测试经理老张。

老王说:老张啊,怎么回事?出什么问题了?我们好不容易开发完成了,你们怎么不测试还把版本打回来了?

老张说:你们提交的版本质量太差,没有我们的预测试,需要重新修改后,符合我们的要求,我们才能测试。你看看我们发现的这两个问题。

老王并没有看这两个问题,而是直接质疑老张:听说你们最近测试环境搭建的有问题,是不是想借版本打回的时间再折腾一下你们的测试环境啊?可不能为了让我们开发的给你们打掩护啊!

测试团队经常会受到提交的版本质量太低的困扰。一旦开发团队提交的版本质量太低,测试过程中就会发现一些非常严重的问题而导致大量的测试用例被阻塞。而非常不幸的是,在项目发布时间不好更改的情况下,这样就会导致测试团队真正能够执行的测试时间被压缩,导致测试的任务无法及时保质的完成。打回版本在对测试团队造成影响的同时,也打乱了开发团队的进度。

于是有些团队就采用了预测试(有时候也称为冒烟测试)的方法,只有通过预测试的版本,测试团队才会开展正式的测试执行。上面的这个场景就是在开展预测试的时候,由于预测试失败而导致的冲突。

测试人员不仅仅是守门员,还应该在需要的时候主动出击。虽然设置预测试是一种提高测试接收的版本质量的一种方法,但是采用预测试的目的不是为了把版本打回去,毕竟回去了,还是要再回来的。测试人员除了被动的在等待开发团队提交版本过来以外,更应该积极的帮助开发人员,尽可能的是的他们能够通过预测试。有些项目中,测试团队积极主动的在测试执行之前帮助开发人员进行代码评审,也会帮助开发人员做部分的测试工作,这样就避免了被动等待。开发团队和测试团队良好互动,共同把项目做好。前期质量提高后,开发人员在测试人员执行测试期间,也可以有少量的开发人力来帮助测试团队。

入口准则在考虑开发因素的同时也应该考虑测试自身的因素。通常都是测试人员去检查开发人员的工作,但是测试人员自己的工作却常常没有得到充分的监督和检查。在制定入口准则的时候,除了对开发人员前阶段的活动的质量提出要求以外,对测试团队应该准备的条件也要进行约束,例如:测试环境的到位,测试用例的评审,自动化测试脚本的编写,测试数据的准备等。

具有可操作和可监控的客观的入口准则。入口准则虽然是针对测试活动的,但是不应该只由测试团队来进行,而应该在更广泛的范围内进行讨论,可以包括开发人员和项目经理等。同时为了符合测试出口准则而发生的活动,并不一定是由测试团队来执行的。例如:预测试可以由开发团队自己完成,而测试团队对测试结果进行检查。但是如果预测试的测试用例本身比较模糊,不同的人执行同样的测试用例可能产生不同的测试结果,那么会造成不必要的麻烦。

SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?,布布扣,bubuko.com

时间: 2024-10-25 01:17:30

SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?的相关文章

SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?

不管是文档化的测试用例,还是存在于测试人员头脑中的测试想法和思维,针对测试对象的分析和设计都是整个测试过程的重要测试活动之一.在进行测试分析和设计之前,测试人员首先需要确定测试的需求来源,即测试用例设计需要参考哪些测试依据文档? 测试用例设计的输入文档是什么?测试人员头脑中第一个蹦出的参考依据就是需求规格说明.确实,需求文档是我们测试设计的最主要参考文档.但是,由于时间限制.成本限制和个人能力限制等方面的原因,提供完备的需求规格说明几乎是不可能的.现实情况是,需求规格说明常常是不全的.模糊的,甚

SWTBOK测试实践系列(3) -- 既然计划永远赶不上变化,我们还要测试计划干嘛?

一天,测试经理老马迟疑着点下了Email的"发送"按钮,长叹一声,往后一仰靠到椅背上.发送这个主题为"回归测试将推迟一周"的通知实为无奈之举啊!一些重要的缺陷开发团队还来不及修复,加上最近几天测试环境的部署经常出现莫名的异常,导致半天都无法测试,原定下周开始的回归测试不得不推迟了!几分钟后,测试人员小王兴冲冲地跑到老马跟前,满脸疑惑地问:"经理,我刚看到你的Email了.又要延期啊!既然我们的测试计划老是在变,干嘛还要定计划?"老马坐正,略带欣慰

SWTBOK测试实践系列(6) -- 开发人员为什么不做静态分析?

场景 某年某月某日,产品环境的2000多封自动发出的Email让我们项目组许多人的邮箱爆了.追查下来根源是一个很不起眼的缺陷.我们的程序对一个布尔值做了if(XXX = true)的判断,可来自上游系统的这个值不光是有true和false,还有空.也就是说上游系统中使用的是一个大布尔,是有true, false,null三态的,  而我们程序使用的是小布尔,只有true和false两态. 掉在大小布尔这个坑里也不是头一回了.记忆中前两年我们也掉进来过.有执著的QA一枚,翻箱倒柜地找,终于找到了当

SWTBOK测试实践系列(1) -- 测试在项目前期的评审投入划算吗?

测试策略:静态测试还是动态测试? [对话场景] 成功发布某个软件版本之后,项目团队召开了项目的经验教训总结大会.在会议期间,项目经理小项和测试经理小测进行了如下的对话: 小项:"小测,我们的项目时间压力很大,测试执行是我们的关键路径,测试团队是否可以在测试执行阶段投入更多的人力和物力?"限定时间和人力资源同等条件. 小测:"啊!假如增加我们的测试执行时间,在整个周期不变的情况下,我们就需要压缩前期的学习和评审投入的时间和工作量,是吗?" 小项:"是的,你看

开发人员与测试人员的那些事

关于开发人员和测试人员的关系,人们阐述了很多,讨论了很多,争论了很多.而貌似一旦这两者坐在一起,对峙便开始了,两者间的争论多于相互认同.显然,这不利于实现两者合作的目标——向用户提供价值.(推荐学习零基础学习软件测试基础篇) 下面我们来分析一下其中的原因: 史前时期 在最开始,不存在测试人员, 只有开发人员.软件开发人员和软件项目的其他人员比起来并没有特别大的不同.从经济角度考虑,专门成立测试人员是行不通的:开发软件的时间如此昂贵,为测试人员分配时间显得很浪费. 没有专门人员检查工作,软件开发人

SWTBOK测试实践系列(9) -- 设计的测试用例是否越详细越好?

测试人员设计测试用例的时候,面临的第一个问题就是测试用例的步骤是否越详细越好?或者如何把握测试用例的详细步骤?在这个问题上,赞成测试用例详细化的人肯定有不少,因为详细测试用例可以提供如下优点: 1)缺乏经验或者技能的测试人员,可以按照测试用例的步骤顺利开展测试执行工作.这是脚本化测试实践中的思维:有经验与技能的测试人员设计测试用例,而缺乏经验的人员去执行测试用例. 2)缺乏经验的测试人员,按照详细测试用例的步骤执行的过程,不仅可以帮助他们了解测试对象的功能与业务知识,也可以帮助他们了解测试设计技

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

软件测试之单元测试:开发人员的测试

说到单元测试,几乎所有人都知道,由开发人员完成.可是为什么要进行单元测试呢? 开发人员写单元测试的时间几乎和他写产品代码的时间相当,因此,当做项目计划的时候,把单元测试考虑进去是合理的.尽管单元测试增加了相当大的开发工作量,看上去开发时间延长了,但实际上对于一个长期不断改进和维护的项目而言,我们不能忽视级联效应,要从项目整体来看. 单元测试可以保证最基本的缺陷尽早的发现并解决,因此,用来解决被流转到后期的测试阶段的缺陷时间实际上就会缩短. 而如果问开发人员是否进行了单元测试,他们通常也会说,是的

测试管理012:结对测试 - 不错的测试实践

由于项目测试中测试平台资源的不足,因此在测试过程中引入了一些结对测试(Pair Testing)的尝试,通过2个月左右的实践,最终的效果还不错.因此,本文简单来谈谈结对测试的实践.不管是开发人员还是测试人员,都应该有属于他们角色的创造性.开发人员创造软件产品,而测试人员可以创造性的发现缺陷,每个角色都可以按照自己的方式前行.开发人员可以结对编程,我们测试人员可以进行结对测试.那么,什么是结对测试呢?不同的人对它的理解会有所不同的.我们定义的结对测试是两个测试人员坐在一起(根据需要,他们可以共用一