yeedomliu
《硝烟中的Scrum和XP》第14章 我们怎样做测试
关注作者
前往小程序,Get
更优
阅读体验!
立即前往
腾讯云
开发者社区
文档
建议反馈
控制台
登录/注册
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
搜索
搜索
关闭
发布
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
yeedomliu
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
社区首页
>
专栏
>
《硝烟中的Scrum和XP》第14章 我们怎样做测试
《硝烟中的Scrum和XP》第14章 我们怎样做测试
yeedomliu
关注
发布于 2020-04-14 14:57:43
401
0
发布于 2020-04-14 14:57:43
举报
文章被收录于专栏:
yeedomliu
第14章 我们怎样做测试
这是最困难的部分
你大概没法取消验收测试阶段
理想化的Scrum世界中,每个sprint最终会产生一个可部署的系统版本
很恶心的bug会因此出现。如果质量对你来说还算重要,你就应该进行验收测试。此时,团队之外的专职测试人员会用测试来攻击系统,而且这些测试是Scrum团队要么考虑不到,要么没有时间完成,或是限于三件条件无法完成的。测试人员会采取与终端用户一模一样的方式来操作系统,也就是说他们必须要手工进行测试
“验收测试阶段”:整个测试、调试、重新发布阶段,直到得到可以用来做产品发布的版本为止
把验收测试阶段缩到最短
全力提高Scrum团队交付的代码质量
全力提高人工测试工作的效率(即,找到最好的测试人员;给他们最好的工具;确保他们上报那些耗费时间、却能够被自动化完成的工作)
我们该怎么提高Scrum团队提交的代码质量呢?
把测试人员放到Scrum团队中
每个sprint少做点工作
把测试人员放到Scrum团队来提高质量
开发人员常常是很差劲的测试人员,尤其是他们测试自己代码的时候
测试人员就是“验收的家伙”
sprint中的任何工作,如果他不说完成,那就不能算完成
开发人员认为“完成”的工作,却根本无法测试!原因包括代码没有提交,或者还没有部署到测试服务器上,等等。他就应该跟开发人员一起浏览一遍“完成”检查列表
妙处由此而生。这下团队中就有了这样一个人,可以完美地担当组织sprint演示的职责
如果没有任何事情需要测试,那测试人员该做什么
这个问题会常常出现
首先,他应该要为测试做准备。包括编写测试规范,准备测试环境等等。开发人员有开发完的功能可供测试以后,就不用再等了,测试先生可以立刻开始测试
如果团队在做TDD,从第一天开始,大家都会花时间来编写测试代码,此时测试人员应该跟编写测试代码的开发人员一起结对编程。如果测试人员根本不会编程,他也应该跟开发人员结对,即便他只能坐在一边看,让开发人员敲键盘。相对于好的开发人员,好的测试人员常常能想出多种不同类型的测试,所以他们可以互补
在sprint计划会议中,进行到拆分故事阶段,团队会把注意力放在编程性任务上,但一般在sprint中都会有很多非编程性任务需要完成。如果在sprint计划阶段花上一些时间来找出非编程性任务,测试先生就有机会来做出大量贡献,即使也不会编程,当前也没有测试工作要做
sprint中需要完成的非编程性任务的例子
搭建测试环境
明确需求
与运营部门讨论部署的操作细节
编写部署文档(版本说明,RFC,或任何在你们组织中要写的东西)
和外界的资源进行联系(例如GUI设计师)
改进构建脚本
将故事进一步拆分成任务
标识出来自开发人员的核心问题并协助解决这些问题
在每个sprint中少做工作来提高质量
这会自动带来质量提升、验收测试周期缩短、影响终端用户的bug减少,并在短期内得到更高的生产力,因为团队可以始终关注于新的东西,而不是不断修复出现问题的旧功能
验收测试应该作为sprint的一部分么
sprint是有时间盒限制的。验收测试(在我的定义中,它要包括调试和再次发布)的时间却很难固定。如果时间用完了,你还有一个严重的bug怎么办?是要带着这个严重bug交付上线,还是等到下个sprint再说?大多数情况下,这两种解决方案都是不可接受的。所以我们把人工验收测试排除在外
如果有多个团队开发同一个产品,那就得等所有团队的工作成果合并以后,再进行人工验收测试。如果每个团队都在sprint中进行人工验收,最后还是要有一个团队测试最终版本,而且这个版本集成了全部团队的工作
sprint周期vs.验收测试周期
在完美的Scrum世界中,你根本不需要验收测试阶段,因为每个Scrum团队在每个sprint结束以后,都会发布一个新的可供产品化的版本
不过下面这张图更符合实际情况了
在sprint1之后,我们得到了满是bug是1.0.0版本。在sprint2中,bug报告开始涌入,团队花了大部分的时间来进行调试,然后又被迫在sprint的中期发布了修复了bug的1.0.1版本。到了sprint2末尾,他们发布了1.1.0版本,提供了一些新特性,但bug数量有增无减,因为他们从上一个版本发布以后就一直被bug所干扰,所以能够用来保证代码质量的时间就更少。然后就一直这样循环下去……
在sprint2中的斜线表明有混乱的存在
我们目前还没有发现这个问题的解决方案。不过还是尝试过许多不同的模型
首先,还是全力提高Scrum团队发布的代码质量。在一个sprint中及早发现并修复bug,要比sprint结束以后再这样做的代价小得多
在sprint结束后还是有bug报告出来。那我们是怎么做的呢?
方式1:“在旧版本可以产品化之前,不构建新特性”
我们不喜欢在sprint之间加上无时限的发布阶段,主要是因为它可能会破坏sprint的节奏。我们再也无法说出“每三周启动一个新的sprint”这样的话来。另外,它也没法根除问题。即使有一个发布阶段,依然会不时出现紧急的bug报告 ,我们不得不为它们做好准备
方式2:“可以开始构建新东西,但是要给‘将旧功能产品化’分配高优先级”
一般我们完成一个sprint以后就会开始进行下一下。但是我们会在接下来的sprint中花一些时间解决过往sprint中留下的bug。如果修复bug占用了太多时间,从而导致接下来的sprint遭到严重破坏,我们就会分析问题产生的原因以及如何提高质量。我们会确保sprint的长度,使之足以完成对上个sprint中一定数量bug的修复
随着时间推移,经过几个月以后,修复上个sprint遗留bug所用的时间就会减少。而且当bug发生以后,所牵的人也更少了,所以不会总是干扰整个团队。现在这种做法已经得到了更多人的认可
糟糕的方式——“只关注构建新东西”
别把最慢的一环逼太紧
假设你的验收测试团队每星期最多测试三个特性(不,我们不会用“每周测试的特性”来进行度量,我只是在这个例子中用一下而已),而开发人员每星期能够开发6个特性
经理或者产品负责人(甚至团队)会觉得不妨安排每周开发6个特性
实际上,应该安排每周只完成3个特性,多余的时间用来攻克测试的瓶颈
让一些开发人员去做测试人员的工作(呃,他们会因此而爱你的……)
实现一些工具或脚本,用来简化测试工作
增加更多的自动化测试代码
延长sprint长度,把验收测试放到sprint里面来
把一些sprint定义为“测试sprint”,其中整个团队都作为验收测试团队进行工作
雇佣更多测试人员(即使这会意味着减少开发人员)
本文参与
腾讯云自媒体同步曝光计划
,分享自微信公众号。
原始发表:2020-04-11,如有侵权请联系
cloudcommunity@tencent.com
删除
单元测试
本文分享自
yeedomliu
微信公众号,
前往查看
如有侵权,请联系
cloudcommunity@tencent.com
删除。
本文参与
腾讯云自媒体同步曝光计划
,欢迎热爱写作的你一起参与!
单元测试
评论
登录
后参与评论
0 条评论
热度
最新
推荐阅读
LV.
文章
0
获赞
0
目录
第14章 我们怎样做测试
你大概没法取消验收测试阶段
把验收测试阶段缩到最短
把测试人员放到Scrum团队来提高质量
测试人员就是“验收的家伙”
如果没有任何事情需要测试,那测试人员该做什么
在每个sprint中少做工作来提高质量
验收测试应该作为sprint的一部分么
sprint周期vs.验收测试周期
方式1:“在旧版本可以产品化之前,不构建新特性”
方式2:“可以开始构建新东西,但是要给‘将旧功能产品化’分配高优先级”
糟糕的方式——“只关注构建新东西”
别把最慢的一环逼太紧
相关产品与服务
测试服务
测试服务 WeTest 包括标准兼容测试、专家兼容测试、手游安全测试、远程调试等多款产品,服务于海量腾讯精品游戏,涵盖兼容测试、压力测试、性能测试、安全测试、远程调试等多个方向,立体化安全防护体系,保卫您的信息安全。
产品介绍
产品文档
精选特惠 用云无忧
领券
问题归档
专栏文章
快讯文章归档
关键词归档
开发者手册归档
开发者手册 Section 归档
0
0
0
推荐