在敏捷(Scrum)实践中，如果团队正在从瀑布向敏捷过渡，我从哪里开始提高QA (测试)的效率？

Question

我的团队最近已经从传统的瀑布方法过渡到实践Scrum。作为QA的领导者，实际上是一个小团队中唯一的测试人员，我如何才能使这个过程与敏捷更加一致？

现在，我们似乎只是在一个迭代中运行一个带有开发的小瀑布，然后在下一个迭代中进行测试(不是敏捷！)。在与程序员进行了一些讨论之后，我发现我们没有设置任何单元测试，所以我们甚至都没有做任何类型的TDD。我们还没有实现任何类型的自动化测试。我不知道该从哪里开始，让我们走上正确的轨道。

Answer 1

到目前为止，您所描述的是一些我称之为“scrummerfall”的东西，但考虑到它的结果，可能是拼写为scrummerFAIL。我认为有几个问题需要解决。@Aruna在他们的回答中包括了几个，这得到了我的高分。在他们所说的话之外，我还要补充以下几点。

1. 在迭代结束时，团队不理解“完成”意味着什么，如果事情没有处于“准备就绪”的状态(例如，仍然需要测试，发现需要修复的bug等等)。
2. 代码似乎没有强调良好的“工艺”，缺乏TDD和单元测试就证明了这一点。在迭代开发环境中，您需要在单元和集成/验收级别上都有一组相当健壮的自动化测试，以确保在早期迭代中正确构建和工作的内容不会被后期迭代中完成的工作破坏。如果这个测试不是自动化的，那么每次迭代结束时所需的回归测试的数量会越来越大，直到它接管了整个迭代，并且无法完成任何工作。作为一个测试人员，您需要在每次迭代中有足够的时间来产生自动化的验收测试，这些测试可以构成一个回归套件的一部分，用于随后的迭代。
3. (在某种意义上，从#2继续)在排序迭代中，提前构建质量是至关重要的，因为在迭代过程中没有足够的时间尝试和‘质量测试’。我强烈地认为，开发人员需要做某种“先测试”的实践，这样才能在长期内取得成功。我知道没有任何其他做法能在降低缺陷率方面产生如此大的影响。最好使用BDD / ATDD (几乎相同的两个术语，但有几个小差异)，否则最好使用TDD。所有的*DD都是设计/开发实践，旨在帮助开发人员通过查看所需的行为来更好地理解他们将要编写的代码，正如测试所表达的，首先是在编写代码之前。当产生单元测试时，它们并不是测试活动，尽管名称中有'test‘，单元测试是开发人员的责任。
4. 他们还没有真正将测试集成到团队中，而且在迭代结束时基本上仍然是“抛出围栏”，这意味着您基本上仍然在单独的筒仓中工作，而不是一个团队的所有部分。当开发人员认为故事正在运行时，您就需要对其进行测试，而不是在他们完成一个sprint之后。
5. 如果您在做scrum时，团队中没有人受过任何与scrum相关的培训(或以前在高绩效团队中的经验)，那么这就是失败的秘诀，请管理层至少为您的SM投资Scrum Master培训，我也强烈建议对PO进行产品负责人培训。
6. 团队中的每个人都需要弄清楚测试是如何适应的，为此，我建议团队中的每个人都要阅读两本关于这个的非常好的书。
   • Crispin & Gregory的敏捷测试
   • Gojko Adzic弥合沟通差距

7. 在社区方面，我强烈建议查看技能问题网站的敏捷测试部分，其中podcast部分有大量优秀的免费内容。此外，Linked中的敏捷测试组也是与其他敏捷测试人员交流的好地方。

Answer 2

1. 在敏捷环境中，测试人员和开发人员之间的区别是模糊的。测试人员不仅要对质量负责，甚至不是质量的主要拥有者。质量是整个团队的共同责任。敏捷团队中的个人可能专门从事某一特定角色，但会根据上下文承担不同的角色。无法深入阅读代码或影响设计决策的测试人员可能需要一些培训(或与DEV配对)才能适应敏捷团队。测试是测试人员、开发人员和客户代表参与的一项关键活动。这是不应该由测试人员单独完成的。开发人员需要在开始编写代码之前编写自动化的单元测试。这种在编码前进行测试的方法称为测试驱动开发。
2. 变更是敏捷项目的核心。当产品发生更改时，测试团队可能会遵循计划。这个计划应该支持这一改变。在实现了更改之后，测试人员需要测试更改中未触及的区域，以确保产品的持续稳定性。
3. 对话和共同理解将取代重量级文档。测试人员应该能够从多个角度看待全局，并提出开发人员和客户可能想到的好问题。
4. 敏捷测试的思维方式是与客户协作，着眼于全局，提供并获得反馈。在这里，测试人员与客户密切合作。与客户密切合作比成为客户代理更有利。测试人员不只是针对协商的工作清单执行，而是与客户进行迭代协作。测试人员在小组会议和错误报告中陈述用户的观点。如果质量无法接受以保护\保护客户，测试人员甚至会失败发布。
5. 测试人员需要保持警惕，注意刚性过程对质量的任何影响。长期以来，测试的焦点一直是短视的，强调的是功能的正确性，而不是对人的价值。测试中的这个问题是刚性过程中较大问题的一个子集。例如，在XYZ公司中，如果测试人员记录了一个缺乏需求规范文档支持的缺陷，则根据流程，该问题被视为非问题。在这种情况下，如果问题确实属于高风险领域，则需要通过与开发人员的共享对话和管理层的高度支持，对问题进行仔细的风险评估。

如果您有兴趣找到更多信息，我还在http://technologyandleadership.com/making-a-successful-transition-to-agile-testing/上写了一篇关于“成功过渡到敏捷测试”的文章。

Answer 3

使用您的测试技能来帮助团队更具体地定义每个故事。这将你的贡献从一个严格的发现问题转移到一个也有助于防止它们的问题。

在为下一次规划会议准备故事时，请与产品所有者和开发人员合作，澄清每个功能的界限。使用你发展完善的边界探测和模糊探测技巧来问“你是指”问题，并假设“如果”情景。帮助团队表达他们对具体的书面例子的理解。

如果您可以将这些示例自动化为自动验收测试，那就太好了。但是即使你做不到，他们也能帮助整个团队更好地理解这个特性，测试他们自己对这个特性的理解，并在系统满足越来越多的例子的情况下，在迭代过程中标记进度。