敏捷：测试任务还是测试任务？ [关闭]答案

【问题标题】：Agile: tasks for testing or testing tasks? [closed]敏捷：测试任务还是测试任务？ [关闭]
【发布时间】：2023-04-07 15:48:01
【问题描述】：

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

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

我们是创建单独的测试任务（当然不能在相应的开发任务完成之前启动，并且会导致一定的任务依赖性和优先级开发）还是我们只是在测试完成后认为任务完成？后一种情况如何在黑板上做标记？

【问题讨论】：

你在说什么样的测试？一些测试，比如单元测试，不应该与编程脱钩；他们是一个无缝的整体。另外，您所描述的听起来根本不像敏捷开发。听起来你在做迭代的迷你瀑布。
集成（功能）测试，当然单元测试由编写代码并在 Jenkins 中保存/运行的同一个人处理。我对标准如何建议这种情况发生感兴趣。在我在线搜索答案时，我不断发现相互矛盾的结果（如果测试任务是单独创建的，那么我们将有一个任务依赖项来跟踪；如果我们将测试作为 DONE 的定义，我们必须添加更多可能任务状态：待办事项、进行中、测试中、完成）。推荐的方式是什么？

【解决方案1】：

我们是否应该创建一个任务来测试每个可测试的开发我们是否应该在将开发任务标记为之前对其进行测试完成了吗？

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

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

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

我们的测试人员和开发人员在计划期间讨论任务，测试人员或开发人员会预先在任务中写一些简短的 QA 说明。再次将测试活动和开发活动保持在同一个地方可以提高两个学科的可见度。

在后一种情况下，我们如何在板上标记它？

我们的管理方式是将未测试任务和测试任务捕获为工单所处的不同状态。我们使用 jira，并创建了具有以下状态的工作流：

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

如果测试人员发现任务有问题，他/她会将任务恢复到 ToDo 状态，并通知开发人员发现的问题。像这样在开发任务中捕获测试活动使我们能够跟踪这些“重新打开”的次数，重新打开的次数多是到达测试团队质量低劣的标志 - 一个问题的指标。

提姆

【讨论】：

【解决方案2】：

你的在线搜索结果会出现很多矛盾的原因是这个问题的解决方案在很大程度上取决于上下文，以及团队的状态。这是团队应该围绕问题自组织的领域。

当您的组织和团队处于一种任务预计会在给定“阶段”出现的状态时，在您的 Scrum 板上创建一个列是有效的。但是，随着您的组织和团队变得更加敏捷，Scrum 板上的列应该折叠，同时打开的故事的数量应该减少。角色将消失，他们将更加有机地和协作地开展工作。

【讨论】：