一旦构建完成，您就可以开始执行测试用例，如果内部版本有所更改，则可以执行测试套件。
每当新版本发布时，都应执行测试套件的完整性检查。 >
#1 楼
定义完成的定义，包括测试。定义完成工作所需的最少测试工作。在编码完成后，甚至在编码过程中，每个故事都有时间框的探索性测试会议，与开发人员结对以测试他们的工作
在UI测试，服务测试和单元测试之间取得良好的平衡，阅读有关测试金字塔的信息报到。因此，您可以进行测试，因为该产品有效。由于工作软件是进度的主要衡量标准。
通过三位好友的会话开始每个PBI，请考虑如何与编码并行地开始测试工作。所有的测试用例，因为您没有时间在每次迭代中进行手动测试回归。质量应建立在产品和周期中。
请记住，敏捷在进行测试时并没有官方的方法。敏捷意味着要完成工作，一次又一次地迭代。如果可行，请继续这样做，如果您无法适应。 XP实践是包括测试在内的最适合敏捷团队的最佳实践。
建议阅读的是《敏捷测试》。
#2 楼
我的团队遇到了类似的问题，即具有多个输入流，这些输入流在不同的迭代/冲刺周期上运行到一个通用产品中。我们尝试在每个区域的开发人员区域中测试一段时间，然后标记当时完成的项目，但是我们很快发现这还为时过早。我们可以验证新功能是否正常工作，但是我们无法在集成级别进行测试，因为集成级别实际上是我们大多数缺陷所在的地方。因此，我们基本上将“完成”的定义移到了下一个周期的下一个时间，我想您可以将它称为“强化冲刺”，因为它是在开发工作发生的初始冲刺之后出现的，或者我们称之为“ QA偏移”。我们的管理团队确实希望在与开发人员相同的时间段内完成“测试”，但是基于我们正在测试的系统类型，这只是不切实际。我们一直在尝试添加不同的自动化层，以帮助我们尽早完成任务，但是要在具有挑战性的旧产品上。
因此，为回答您的原始问题，我们通常会监视内部版本，只要其中包含足够多的项目，我们就会抓住它们并开始测试。由于我们是每天进行生产，因此大约每隔一天我们将重新开始测试，其中包括新功能和微型烟雾，以验证较旧的项目是否可以继续工作。
评论
这似乎与我正在做的事情相似，现在只是我作为质量检查人员，因此很难处理所有问题。但是我通常会观看我们的trello董事会故事，当有相当数量的资金转移并创建了新版本时，我将开始测试
– Merfh
16年1月12日在16:05
敏捷进行质量检查似乎是最困难的部分。给您一个问题，您的测试任务在哪儿进行？现在，我有PBI / Bug，其中包含所有开发工作和测试任务的任务。在完成所有任务之前，我无法将PBI / Bug标记为已完成，但是我的测试任务可能与开发任务不在同一迭代中。所以我应该在下一个开发迭代中，还是我们已经进行了单独的质量检查迭代。因为我们不想对开发人员燃尽图产生负面影响。您是否尝试将测试任务保持在同一迭代中？
–QA Prescott
16年1月14日在15:03
好吧，我们仍然有点习惯于敏捷方法，因此我通常会在构建时进行测试，因此会测试与开发人员相同的迭代。
– Merfh
16年1月14日在15:07
#3 楼
如其他答案和评论所示，这是我在多家公司工作中遇到的一个常见问题。仔细考虑一下，我怀疑大多数公司都在挣扎着这样的通用问题：留出足够时间进行质量检查，测试功能一旦完成，就可以实现自动化。通常，人们可能会觉得敏捷解决方案没有明确的指导。 ：
1）测试在开发工作之前，之中和之后进行。例如，如果您练习BDD并在应用程序代码之前编写了失败的测试，那么您将离保持最新目标更近一步。
2）可能需要一点纪律以留出更多时间进行质量检查。例如，很容易地说：“我们将更改为开发人员工作一个星期，然后质量检查有一个星期要测试的过程”。实际上，工作通常不会在第一周完成，而是溢出到第二周，再次导致相同的情况。尝试通过正式的计划营业额和里程碑来解决这个问题。例如，日历提醒“现在是星期五下午3点。您的代码准备好进行测试了吗？”您还需要考虑如果不允许更改，开发人员将在一周内做什么？闲置一个星期是行不通的。这个难题很难得到解决，这要归功于对问题和因素的大量探索以及经验丰富的资深人士的帮助。 >总结：您需要在开放和关怀的环境中与开发过程中的所有利益相关者进行详细而艰难的对话，以鼓励在无威胁的有趣工作场所中所有观点，在这里错误只是人们学会正确做事的方式事情。换句话说，是一种良好的文化。
#4 楼
仅当开发人员已在某种程度上开发了该功能时，才可以测试在sprint中创建的特定功能。同时，当开发人员忙于开发功能时，质量保证人员应根据功能说明文档或用户故事开始进行测试计划/测试案例。如果质量检查团队正在自动化测试用例并使用诸如Cucumber之类的BDD工具，则他必须开始为测试用例编写Cucumber以节省时间。质量检查人员应与开发人员保持持续联系，以使他至少获得一部分已开发的功能。一旦收到开发的模块，现在的质量检查人员就可以进行大量工作。他首先应该对收到的模块进行完整性检查，然后快速记录在错误跟踪工具中发现的问题。另外，就此问题与开发人员进行沟通。并排他还应该使测试用例自动化。需要快速处理此循环，以便在冲刺结束日期当天或之前，测试并交付每个模块而没有任何错误。因此，换句话说，一旦在sprint中收到功能规格或用户故事，就开始质量保证工作，并且一旦开发人员开发了功能的某些模块，就可以开始实际测试。
#5 楼
我的想法很简单。准备回归自动化套件并在CI和CD管道中进行设置，并将其添加为构建后操作。在Sprint中，应该开始重复任务的自动化，并每天将其推送到CI CD管道中。#6 楼
保持简单！在整个sprint中进行测试！
是的，这意味着在整个sprint中进行部署！
但是如何！
开发人员应该继续努力。
他们只会如果正确执行了最容易被忽视的敏捷规则，即低估和承担每个开发人员在sprint周期内所能完成的工作，那么该工作就能取得成功。我如何胜利！
我解决了敏捷测试瓶颈问题！
https://medium.com/@salibsamer/i-solved-scrum-sprint-end-testing-bottleneck-problem-bfd6222284a1
评论
不幸的是我不能投票10次。 “定义完成的定义，包括测试。”即使非敏捷也非常有用。关键是“敏捷没有官方方法”：敏捷意味着您应该使用最适合特定情况的方法。
–gazzz0x2z
16年1月12日在8:47
自动化的问题（就我而言）就是我。我无法（或没有时间）为我从事的所有项目自动化这些类型的事情。我想找到完成的定义可能是我需要努力的目标。但是据我的理解，您是说“ Story”经过测试并且“完成”后，我真的不应该在每次出现新版本时都返回并重新测试（至少直到回归）。因为我认为那是我遇到麻烦的地方（我花了多少时间来重新测试“旧”东西）
– Merfh
16年1月12日在14:59
在敏捷团队中，团队负责完成完成的定义。如果测试人员是自动化测试用例的瓶颈，那么团队中的其他人应该提供帮助，否则团队什么也做不了。是的，我是说您应该避免每次迭代都重新测试较旧的功能。现在，我了解到转向敏捷的团队可能并没有真正的文化去做将这部分软件投入生产所需的一切。一些团队会每隔2-3个冲刺引入一次强化冲刺。参见：agilerecord.com/hardening-sprints也许是时候进行全面回归了。
– Niels van Reijmersdal
16年1月12日在15:06
强化确实很有意义，这就是定义。适应敏捷方法的调整哈哈
– Merfh
16年1月12日在15:12
我个人（与开发人员一起）调查代码以检查更改的影响。借助这些知识，我尝试考虑哪些零件受到此更改的影响（自动）的测试覆盖率较低。然后，我仅在这些部分上增加一些额外的关注。如果开发人员使用SOLID模式，则大多数代码将解耦，并且影响应始终相对较低，并且影响很容易估算。为紧密耦合的组件添加更多测试。如果代码更改破坏了意外区域，则代码将被耦合。这不是您要通过测试解决的问题，而是具有更好的体系结构。
– Niels van Reijmersdal
16年1月12日在15:13