在三个答案中，有两个答案表明每两个周期的冲刺就会加强。还提到了在整个sprint中添加探索性测试。
但是在看板中，理论上您可以决定随时发布。您如何将回归或其他“整个系统”测试（例如性能/负载测试）纳入其中？
#1 楼
使用看板，您不会真正感到冲刺结束的问题，您可以满意地对功能进行了全面测试并可以正常工作，因此不需要等效的强化冲刺。取而代之的是，您将工作项保持在测试状态，直到您拥有一组强大的自动测试来验证接受标准为止。限制进行中的工作意味着有很多测试任务，然后团队将需要集中精力减少这种工作，然后才能开始新的工作项。性能和负载测试应该正在进行，并且是其中的一部分测试状态，并根据需要将其添加到进入该状态的每个工作项目中。
对于探索性测试，您可以安排时间，例如每个星期一上午9点至上午11点，整个团队将做探索性测试，然后讨论结果。
您还需要一种机制，以防止不完整的功能脱离已部署的版本，例如功能开关，该功能允许您打开和关闭特定功能。 br />
#2 楼
在许多情况下，您会努力工作以使尽可能多的回归/性能/负载测试自动化并按每晚运行（由于这些测试通常可能需要花费多个小时才能运行，因此您不希望使用每个CI版本，但您确实希望它们尽可能定期地定期运行，对新功能进行运行的验收/回归测试是使该项目按原样通过管道的最后阶段之一，因此不应发布如果这些东西不在线且无法运行。#3 楼
在我看来，部署节奏几乎总是比交付（开发人员）节奏更低。此外，只有通过关键数量的组件，您才能为客户带来价值。此外，通常还会有一些遗留软件可以抵抗自动化测试。另外，（但不是最终），没有人想到自动化的木制品，也许是因为解决方案或技术设计刚把它弄错了。始终适合拥有“超级故事”，每个故事都取决于正在传递到管道中（未部署）的大量故事，这些故事可以进行探索性和用户测试，并以部署结束。 >我的帽子太老了吗？评论
对我来说听起来并不算老。
– testerab
2014年4月3日在8:33
哦-欢迎使用SQA @ mark-g！
– testerab
2014年4月6日23:16
评论
因为没有什么比周一上午9点手动测试说“这是很棒的一周”了！ :-D
–corsiKa♦
2011年5月18日在22:12
@glowcoder-您轻松的评论引发了一系列思考，引发了更多问题:)-这次让他们进行聊天，尽管它更适合讨论。
– testerab
2011年5月18日在22:31
@stuartf-好的-让我检查一下我对您正在做的事情的了解，因为我不确定：我听说您正在结合使用自动回归检查和定期对整个应用进行探索性测试，这并不排除进一步测试功能本身（即接受标准检查是功能测试的一部分，而不是全部）。我最初读到您的回答是说自动化测试是整个功能测试的全部，但是现在我不确定这是否是正确的解释。
– testerab
2011年5月18日在22:38
@testerab我不是说我允许一个小时的探索性测试，我说设定一个固定的时间段每周进行一次探索性测试（如果需要更多的话，您可以每天做一个小时），持续时间取决于您的想法是适当的。仅在分配的时间内执行此操作，因为您的优先级是在工作流程中移动工作项，因此您应该集中精力将工作状态从测试状态移动到工作流程中的下一个状态。您可以随时进行部署，这不会在探索性测试后发生，通常会在工作项进入部署状态时发生。
–stuartf
2011年5月18日在22:40
糟糕-对不起，我删除并重新写了您刚才回复的评论！
– testerab
2011年5月18日在22:42