Scrum是一种迭代式与增量式的框架，它体现了软件开发的一种敏捷式的途径。在软件组织中，使用Scrum进行软件应用开发与测试正在变得越来越流行。
在Scrum团队中，测试与开发同样重要。在每个Sprint中，测试人员需要在特定的、极短的时间内对特性进行测试，以帮助团队尽早地消除bug。
虽然敏捷测试比起传统的测试方法存在着许多优势，但它也有不足之处，其中之一就是有时它会在每个Sprint临结束时对质量保证（QA）团队产生了过多的压力，最终可能会导致Sprint的溢出。
测试人员所面对的另一个问题是缺乏全面的文档。在敏捷项目中有一个严重的陷阱，就是缺乏对设计与文档的强调，因此造成了许多需求的模糊不清。虽然人们说过多的细节文档会妨碍重要的工作，但我认为可以在某个敏捷项目管理工具中维护每个用户故事的适当细节、文档以及每种可能的场景，以此解决这一问题。
QA团队无法对几周之后的工作内容进行规划，在敏捷项目中，测试人员必须在代码开发的同一个迭代内进行代码的测试，并且要求他们为代码及整个应用提供快速的反馈。不过，在大多数情况下，可运行的代码只在一个Sprint临近结尾时才能够提交，此时由于demo或演示的需要，代码往往要处于冻结状态。其结果就是测试团队往往缺乏足够的时间进行验证，因此往往对某个特定Sprint的测试会推迟到下一个迭代中，此时才会将这些工作丢给测试团队。
在Scrum，测试人员的工作不仅仅是进行测试，并在缺陷跟踪工具中记录bug，而是包含了多种不同的任务，例如测试管理和分析以及测试执行的职责。除此之外的职责还包括客户处理，以及bug的跟踪，还有将客户不断建议的频繁变更进行集成。
真正的敏捷QA往往还要负责非单元测试工具、测试环境搭建以及测试数据的准备。处于这一角色上的人会发现他们需要在互相冲突的选择中进行权衡。这些选择与非敏捷项目中的选择相类似，但由于敏捷项目的时间短暂，使这些问题显得更为突出。对于测试进行管理的职责往往分派给某个敏捷团队中的一个或两个成员，而不是由整个团队承担起这一任务。
虽然在敏捷项目中进行工作会让你始终保持警觉，但分散的职责以及更好的时间管理能够让你的工作更简单，同时也更高效。
时间估算是敏捷测试人员的一大挑战，要进行准确的测试估算，需要考虑到多个重要的因素，例如项目的范围、所需的测试类型、测试任务以及以往的经验。但有时即使是最精确的估算方式也会最终显得时间不足，这是因为每个Sprint结束前的测试时间过于短暂，因此QA无法进行足够的端到端测试。如果在先前的开发过程出现了任何延迟，都有可能影响QA的时间安排，有时QA无法在整个迭代中完成某个测试用例的执行，因此他只能选择快速的完成。在估算过程中，QA有责任提醒整个团队必须执行的测试任务，因此让团队成员不会对任务过分承诺。这里的估算应当包括手工任务和自动化任务，团队或许需要对某个用户故事编写或改写自动化测试。
在敏捷测试中的另一个障碍是在测试过程中缺乏客户的参与，客户或许会认为他们只需要在产品完全结束之后再参与就足够了。这会导致验收测试和验收标准方面的问题。我们在演示过程中很少会收到下一步应该做些什么的反馈。建立一种信任关系有助于缓解这一风险。
在我之前的一个项目中，我曾看到客户建议对应用程序的核心功能进行巨大的改动。这种改动会影响应用程序中的其它特性，并且导致代码的改动，并且使测试工作量倍增。从客户那里得到的反馈时间太晚，会推迟产品上线的时间。让业务人员专门负责与客户进行每日沟通，能够填补在客户响应时间上的鸿沟。
敏捷的一个主要优势是能够尽早地开始测试。随着项目逐渐成熟，敏捷测试也变得越来越重要。每个特性在开发完成之后就应当进行完整的测试，而不是在整个开发结束后再开始测试。
在项目的早期完成了几个成功的迭代之后，用户故事与工作量会开始增长，而项目也需要加入更多的团队成员。随着开发人员数量的增长，测试人员的数量也应当随之增长，以维持一个恒定的测试人员/开发人员的比例（通常是一个测试对应两个开发人员）。
现在，让我们假设以上情形在每个Sprint（大约两周到四周）中都会重复出现。从客户的角度来看，在每个循环中，敏捷测试都需要对一个或多个新的软件模块进行验证。还需要考虑在最终发布之前如何、以及何时处理回归测试的问题。测试不再是软件开发的一个阶段，而是与开发混合在一起，持续的测试是确保持续前进以及最终成功的咒语，也是唯一的方法。
在每个Sprint的过程中，敏捷测试将对每个新的功能进行检验。通常来说，在每个Sprint的结束之前，需要保留一小段时间以进行回归测试，然后才能进入下一个Sprint。敏捷团队常常会实现一种构建验证测试（BVT）程序，团队通过它实施一个标准的验证步骤集，它将横跨整个应用程序，以确保应用程序的稳定性与功能性。如果可能的话，应当将这种程序进行自动化，并集成为持续集成服务器的一部分，这将使发布过程更加严格。
对于跨多个Sprint的项目来说，一种标准的实践是在其中设置一个代码强化Sprint，或发布Sprint，从整合的观点来看，能够确保应用程序的整体功能。良好的情况下，假设在每个Sprint中都小心翼翼地处理了缺陷的问题，那么这个过程不应该超过30天或45天。可以通过为每个用户故事和bug设定手动与自动化测试的目标以实现这一点。QA有责任将任何尚未实现自动化的用户故事和bug标注为手动。这样，在新的构建部署之前，我们就能够获得一个可以手动执行的回归测试的集合。对于自动化来说，我们应该维护一个良好的自动化测试套件，在开发者每次提交代码时作为一个持续集成任务自动运行。
每个Sprint中，我们都在添加新的特性，或是发动现有的特性。我们也需要确保之前所创建的功能还在继续正常运行。一个自动化测试框架能够帮助团队快速地进行测试并找到bug。这不仅是对于新的开发任务所产生的回归缺陷的一种安全保障，同时也节省了开发者与测试人员的宝贵时间，让他们专注于自己最擅长的工作上。
但是，由于每个Scrum Sprint的时间限制，同时编写自动化测试用例以及进行手动测试就成为一个很大的挑战。为了克服这一挑战，我们团队对于每个用户故事完成的定义加入了一个规定：如果某个用户故事的适当路径（happy path）还没有完成自动化，那么就不能够开始进行测试。通常来说，让一个开发者与一个QA测试人员共同合作编写适当路径是一种优秀的实践。
有些情况下，在一个Sprint中对非功能性方面进行测试是不可能的，例如系统的性能。对于每个非功能性方面的测试都应当创建新的用户故事，并独立估算时间。此外，这些测试也应当实现自动化，并加入到回归测试套件中，以确保缺陷修复后的系统还能够继续正常运行。如果整个系统是持续集成的，并且使用了自动化测试，那么也许就不必对其进行严格的集成测试了。
