从测试人员的角度看敏捷中的障碍.pdf

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