求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
敏捷性测试团队才是王道
 

2010-12-20  来源:网络

 

最近常51上晃,今天看到一篇帖子,对偶的触动很大,名字是《生命周期半年的项目需求是否有必要写用例》,LZ提出了这样一个问题:对于稳定客户的项目类测试,经常会遇到需求三天一变,两天一变,由于时间周期不是太长,客户需求经常变动,导致BA/PM等都未能及时更新需求,从而给测试组的需求经常是非最新版本,且测试阶段的需求也经常有小变动,导致用例效果不大甚至失效.(可能是针对需求说明书失效,更多情况是针对实际需求-即系统实现方式失效)

看了这个问题偶不禁想到以前测试生活的总总~,真是往事如风...

以下是偶对这个问题的个人意见,

1、LZ的题目中缺少两个关键属性:项目的规模(包括需求变更规模)和测试资源

2、浅析项目规模和测试资源的影响

其实LZ这个题目最大的争议点就是在这里,如果这两个属性可以确定,相信大家的思路会清晰很多。下面偶只分两类进行简单的分析:

A、项目规模大(需求变更规模大),测试资源少:按照CMMI 5中测试用例的编写标准来说,限定6个月的时间。测试团队需要完成测试策略/计划的拟定和评审、测试用例的设计/评审/修改、变更需求的评审/修改、新需求测试用例的设计/评审/修改...

显而易见,剩余还有多少时间完成测试执行的跟踪和改进?即使前期能勉强跟进,偶相信在后期也只能疲于奔命,敷衍了事,什么“测试驱动开发”也只是梦中花而已。

国内很多企业都是这样的情况,相信N多测试同仁对此是深有体会。

B、项目规模小(需求变更规模小),测试资源多:人多好办事,只要Test Manger不是个草包,将测试工作进行有条理的细分,责任到人,在测试准备阶段选择有利于修改的测试流程(包括简易需求和测试资源变更流程以及便于变更的测试用例模板等等),在测试执行阶段,注意需求收集已经各部门以及客户之间的信息交流,还是很容易搞定的。

3、浅析正方观点的风险:

A、如正方wuyu702 所说:“先会把大概的用例写出来,测试的过程中,不停的添加用例。最后测试完了,用例也出来了。。”。

什么叫大概的用例?

用例最基本的要求就是任何测试人员都可以操作,敢问你如果写出这样缺斤少两的用例,当你临时有其他更重要的任务,然后把这块测试工作交付给其他人来做,能够保证别人肯定能看明白?

B、又如正方Okayde、wuyu702、jessies、兆隆8032等提出的:用例是用来保障测试的质量,以及对测试执行的指引。

测试用例是唯一的保障产品/测试质量的手段?没有测试用例就无法指导和跟踪测试执行了?

当然不是,这里偶引用一个只有部分公司在用的一个概念“测试规程(test procedure)”。它是个提供详细的测试用例执行指令的文档。测试规程更注重测试的流程、方法等比较泛的内容,以方便对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。

测试规程与测试用例的区别:理想化的测试用例确实需要很多测试数据集合,但是现实中对某一软件进行测试时,由于涉及的面太广,无法一一列举出所有数据,所以要根据公司的规范来做相应的调整。所以,测试规程的文档编辑量较轻,但是只适合熟练的测试人员执行,而测试用例的执行者可以使任何人。

楼上很多同仁谈到的根据实际情况写简化用列的做法实际就是将设计测试用例变为设计测试规程,然后以测试规程来指导测试执行,提供测试质量(比如测试覆盖率)的评估。但是楼上的同仁没有对简化测试用例提出标准?如果一个测试团队里有3、4个简化标准,大家的测试用例简化的“度”都不一致,岂不乱套?

C、2A中描述的项目情况,仍采用设计常规的测试用例的方法,那么只能有两种结果:a、披着“测试用例”的外套,却是到处缺胳膊少腿,敷衍了事,难以达到测试用例的覆盖标准;b、忙于测试用例的编写,无法在测试执行中完成测试的跟踪与改进,每天都疲于奔命,最终完成N个项目后,测试团队的水平仍然停滞不前,经常受到项目组的“鄙视”。

4、偶的观点:敏捷性测试团队才是王道,项目不同测试流程不同。针对LZ的项目,选择测试规程代替测试用例是明智之举。下面偶只针对与设计测试规程有关的部分提出一个简单的方案。

A、前提:测试团队组成基本由熟练测试人员组成(就软件黑盒测试来说,加入团队半年以上的就可以叫做熟练了)。统一规范的测试流程(相信这个只要是稍微正规点的公司都有)PS:此流程只适用于2B的情况,并且可以进行裁减。有些公司是将标准流程做成checklist形式,方便项目组选择。

B、策划:测试负责人根据项目实际情况在测试准备阶段裁减出适用于该项目的测试流程,并进行评审。其中有两点必须说明:测试执行依据采用测试用例还是测试规程或者两者皆用;测试用例(测试规程)设计的标准。

C、变更:满足以上两个条件,如若遇到实际需求被迫变更,则修改相应测试规程,并评审即可。修改测试规程和修改测试用例在工作量上存在很大的区别,偶举一个例子:

为了简单,用例和规程的格式就忽略了,只写具体输入步骤一部分,书写格式也比较随意。

原需求:编辑框A中允许输入最多20个中文

规程的输入步骤:

只输入0~20个中文,点击确定,检查结果。备注:其中0、20必须测试

输入21个中文,检查结果

输入非中文字符,检查结果。备注:包括英文/特殊符号...

混合输入中文与非中文字符,检查结果。备注:中文字符在第一位的情况必须测试

...

测试用例的输入步骤:

不输入任何字符,点击确定,检查结果

输入10个中文字符,点击确定,检查结果

输入20个中文字符 ,点击确定,检查结果

输入21个中文字符,点击确定,检查结果。

....(不写了,N多)

假如修改需求:编辑框A中允许输入最多20个中文或数字

规程的输入步骤:

输入0~21个中文或数字,点击确定,检查结果。备注:数字/中文混合输入、0/20/21位字符输入必须测试。

....

假如换成测试用例,那就只有....慢慢写了~

D、跟踪/评估:其实从4C中的例子可以看出,测试规程是可以对测试质量进行跟踪和评估的。当然还有其他很多测试质量评估方法,比如交

叉测试、缺陷分析



如何有效地进行项目沟通
如何进行项目计划及质量管理
IT项目风险管理案例和应对之道
组建高效快速研发团队的必要
一个甲方项目经理的自白
TFS使用指南


软件项目管理
软件开发项目管理
研发项目管理
高级项目管理实战
敏捷项目管理实践
项目风险管理

相关咨询服务
建立项目管理规范


中国银行 IT外包项目管理
北京软件项目管理
某电子软件中心 项目外包管理
某电信服务商 项目外包管理
富士 软件外包项目管理与进度
Schneider 项目管理+软件质量
中国电信 软件项目管理