在sprint的什么时候应该涉及功能测试资源?

时间:2010-02-18 02:40:23

标签: scrum functional-testing

我们由三位开发人员组成的scrum团队拥有专门的测试人员。目前,在我们为期两周的冲刺的第一周大部分时间里,测试人员表面上都在等待测试。我们通常会在sprint第1周的周四或周五进行第一次sprint交付。此时我们的测试人员可以“测试”胚胎软件。

这在我的脑海中引出了一个问题 - 这样的功能测试有多大价值,所以在可交付成果的早期发展中如此?

在现阶段(冲刺第1周结束)开发过程中,如果测试推迟了几天(比如冲刺的第2周),通常会出现明显的错误/功能遗漏。

在这种情况下,最佳做法是什么?

5 个答案:

答案 0 :(得分:3)

虽然您提到了一个良好的管理实践Scrum,但您没有描述您正在使用的测试实践。

如果您使用的是最佳做法,那么您应该使用测试驱动开发。

测试驱动开发意味着测试必须从一开始就完成。程序员必须编写测试并填写通过这些测试的类。

测试人员应该在第1天编写功能测试 ,应用程序绝对无法在第1天通过。最终,应用程序开始通过这些测试,您可以调用您的sprint。

如果您没有进行测试驱动开发,那么您应该是,并且您的测试人员应该编写集成测试用例。

如果您的测试人员无法编码,请教他们编码。你必须有一个可以编码的测试人员。并让他们在第1天开始编写功能测试

答案 1 :(得分:3)

测试人员可以查看规范并编写测试脚本/验收标准步骤。

由于开发人员正在完成一项任务,但在办理登机手续之前,他们也可以进行迷你测试评估,即与开发人员进行5分钟的关注,因为他们正在完成工作,这通常会导致一些错误。< / p>

总是会测试现有的应用程序(假设这不是新产品的第一个冲刺),总是会发现错误。

然后存在现有错误的分类,是高优先级还是低优先级。

然后是测试和关闭开发人员已修复的错误。

当然,最重要的是制作咖啡并擦拭任何举手的开发商的眉毛。

答案 2 :(得分:1)

您发现了产品Backlog的问题。如果您有3个开发人员编写3天没有可测试/可释放的代码,那么您的故事太大了。你应该注意到这反映了你在燃尽时的这个事实;平线 - &gt;冲刺结束时大跌。集成应该是日常例程,新功能始终可用于测试。

答案 3 :(得分:1)

我同意上述内容。当您为春天选择用户故事时,您应该开始定义它们的测试方式

答案 4 :(得分:0)

怎么样:

  • 自动化手动测试的最后一个sprint中的一些故事测试

  • 自动设置测试数据(和/或机器),以便更快地进行下一轮回归测试。

  • 编写一些故事的测试规范,以便开发人员在完成这些故事时获得更好的信息。