我想知道标准在这种情况下建议的最佳做法是什么：
在为用户故事创建任务时，我们通常会有开发/设计/文档/测试任务。我们是否应该创建一个测试每个可测试开发可交付成果的任务，我们是否应该在将开发任务标记为完成之前对其进行测试？
我们是否创建了单独的测试任务（当然在相应的开发任务完成之前无法启动，并且会导致某个任务依赖性和优先级开发）或者我们只是在测试完成后才考虑完成任务？在后一种情况下，我们如何在电路板上标记它？
答案 0 :(得分：1)
我们是否应该创建一个测试每个可测试开发的任务 我们应该在开发任务标记之前对其进行测试 完成？
您应该在将任务标记为完成之前对其进行测试，否则可能很难评估特定开发任务的状态。
此外，它会在您的开发任务与其包含的信息（例如用户故事，开发人员，对该任务持有的任何澄清或讨论）以及您的测试任务（可能具有该任务）之间创建和人为地断开连接。自己的澄清和讨论）。
测试是一个双向过程，因此测试人员应该了解开发人员所做出的决策，同样开发人员应该看看测试人员计划进行测试的是什么。
我们的测试人员和开发人员在规划期间讨论任务，测试人员或开发人员会先将一些简短的QA笔记写入任务。再次将测试活动和开发活动保持在同一个位置可以提高两个学科的可见性。
在后一种情况下，我们如何在电路板上标记它？
我们如何管理它，是将未经测试的任务和测试的任务捕获为故障单所处的不同状态。我们使用jira，并创建了具有以下状态的工作流：
ToDo -> InProgress -> PullRequested -> Merged -> Resolved
如果测试人员发现任务有问题，他/她会将任务重新置于ToDo状态，并通知开发人员发现的问题。保持在这样的开发任务中捕获的测试活动允许我们跟踪这些重新打开的次数，高水平的重新打开是表明质量差的一个标志，它们是一个问题的指标。
添
答案 1 :(得分：0)
您的在线搜索结果中存在许多矛盾的原因是此问题的解决方案在很大程度上取决于上下文以及团队的状态。在这个领域，团队需要围绕问题进行自我组织。
如果您的组织和团队处于某种状态，其中某个任务预计会在某个阶段进行，那么在您的Scrum板上创建一个列是有效的。但是，随着您的组织和团队变得更加敏捷，您的Scrum板上的列应该崩溃，并且同时打开的故事的数量应该缩小。角色将消失，他们将更有机地和协作地开展工作。