硝烟中的 Scrum 和 XP(四)

博客围绕Scrum团队的测试工作展开,提出将验收测试阶段缩到最短,可通过把测试人员放入团队、每个sprint少做工作来提高代码质量。还探讨了验收测试是否作为sprint一部分、Sprint周期与验收测试周期的关系,以及针对最慢环节给出了多种解决办法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

                                                              我们怎样做测试

把验收测试阶段缩到最短


把需要花在验收测试阶段上的时间减到最少

  • 全力提高Scrum团队交付的代码质量。
  •  全力提高人工测试工作的效率(即,找到最好的测试人员;给他们最好的工具;确保他们上报那些耗费时间、却能够被自动化完成的工作)

 

该怎么提高 Scrum 团队提交的代码质量呢?我们发现下面这两种办法效果很好:

  • 把测试人员放到Scrum团队中
  • 每个sprint少做点工作

 

把测试人员放到 Scrum 团队来提高质量


测试人员就是“验收的家伙”

如果没有任何事情需要测试,那测试人员该做什么?

首先,他应该要为测试做准备。包括编写测试规范,准备测试 环境等等。

 

在每个 sprint 中少做工作来提高质量


简单来说,就是别把太多故事都放到sprint 里面去!如果碰到了质量问题,或者验收测试周期太长,干脆就每 个 sprint 少干点!这会自动带来质量提升、验收测试周期缩短、影 响终端用户的 bug 减少,并在短期内得到更高的生产力,因为团队 可以始终关注于新的东西,而不是不断修复出现问题的旧功能。

 

验收测试应该作为 sprint 的一部分么?


有些团队把验收测试当成了 sprint 的一部分。但大部分团队都没这样做。

 

Sprint 周期 vs. 验收测试周期


在 sprint 1 之后,我们得到了满是 bug 的 1.0.0 版本。在 sprint 2 中, bug 报告开始涌入,团队花了大部分的时间来进行调试,然后又被 迫在 sprint 的中期发布了修复了 bug 的 1.0.1 版本。到了 sprint 2 末 尾,他们发布了 1.1.0 版本,提供了一些新特性,但 bug 数量有增 无减,因为他们从上一个版本发布以后就一直被 bug 所干扰,所以 能够用来保证代码质量的时间就更少。在 sprint 2 中的红色斜线表示出了混乱的存在。

解决办法:全力提高 Scrum 团队发布的代码质量。在一个 sprint 中 及早发现并修复 bug,要比 sprint 结束以后再这样做的代价小得多。

方式 1:“在旧版本可以产品化之前,不构建新特性”

方式 2:“可以开始构建新东西,但是要给‘将旧功能产 品化’分配高优先级”

糟糕的方式——“只关注构建新东西”

 

别把最慢的一环逼得太紧


有些团队把验收测试当成了 sprint 的一部分。但大部分团队都没这样做。

假设验收测试是你那里最慢的一环。测试人员稀缺,或者低劣的代 码质量造成了过长的验收测试周期。

  • 让一些开发人员去做测试人员的工作
  • 延长sprint长度,把验收测试放到sprint里面来。
  • 把一些sprint定义为“测试sprint”,其中整个团队都作为
  • 验收测试团队进行工作。
  • 雇佣更多测试人员(即使这会意味着减少开发人员)。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值