敏捷:用于测试或测试任务的任务？

Question

我想知道在这种情况下，标准推荐的最佳实践是什么：

在为用户故事创建任务时，我们通常有开发/设计/文档/测试任务。我们是否应该创建一个任务来测试每个可测试的可交付开发版本，因为在标记为完整之前，我们应该测试一个开发任务吗？

我们是创建单独的测试任务(当然，这些任务不能在相应的dev任务完成之前启动，并且会导致特定的任务依赖和优先级的开发)，还是简单地认为任务一旦测试就完成了呢？在后一种情况下，我们如何在董事会上标记它呢？

Answer 1

我们是否应该创建一个任务来测试每个可测试的可交付开发版本，因为在标记为完整之前，我们应该测试一个开发任务吗？

在将任务标记为完整之前，您应该对其进行测试，否则可能很难评估特定开发任务的状态。

此外，它会在您的开发任务和它们包含的信息(例如用户故事、开发人员、对该任务的任何澄清或讨论)和您的测试任务(可能有它自己的澄清和讨论)之间创建和人为地断开连接。

测试在很大程度上是一个双向的过程，因此测试人员应该了解开发人员所做的决策，同样，开发人员也应该了解测试人员的测试计划。

我们的测试人员和开发人员在计划期间讨论一项任务，测试人员或开发人员将在任务中预先编写一些简短的QA备注。同样，将测试活动和开发活动保持在同一个位置可以提高跨两个学科的可见性。

在后一种情况下，我们如何在董事会上标记它呢？

我们如何管理它，是捕获未测试的任务和测试的任务，因为票据处于不同的状态。我们使用jira，并创建了一个具有以下状态的工作流：

ToDo -> InProgress -> PullRequested -> Merged -> Resolved

• ToDo：在sprint中，准备工作。
• InProgress：开发人员积极处理任务
• PullRequested：PullRequest在git中打开以供团队评审
• 合并了：合并到特性分支并部署到测试环境中。就在这一点上，测试人员会捡起它并进行测试。
• 解决了：测试人员已经测试并接受了这个任务。

如果测试人员发现任务有问题，他/她会将任务重新放入ToDo状态，并将发现的问题通知开发人员。保持这样的开发任务中捕获的测试活动可以让我们跟踪这些“重新打开”的数量，而高级别的重新打开是测试团队质量不佳的标志--一个问题的指示器。

时间

Answer 2

在你的在线搜索结果中会有很多矛盾的原因是这个问题的解决在很大程度上取决于环境和团队的状态。这是一个需要团队围绕问题自我组织的领域。

当您的组织和团队处于期望某种任务处于给定“阶段”的状态时，在scrum板上创建一个列是有效的。然而，随着您的组织和团队变得更加敏捷，scrum板上的列应该会崩溃，同时打开的故事数量应该会减少。角色将消失，他们将更有机地和协作地做工作。