在敏捷（Scrum）实践中，如果团队从瀑布式过渡到敏捷，那么我应该从哪里开始以提高QA（测试）效率呢？

#1 楼

到目前为止，您所描述的是我称之为“ scrummerfall”的内容，但鉴于实际情况，可以将其拼写为scrummerFAIL。我看到有几个问题需要解决。 @Aruna在他们的回答中涵盖了几个，这给我很高的评价。在他们所说的内容中，我要补充以下内容。

1）如果事情未处于“准备就绪”状态（例如，仍需要进行测试，错误，需要在迭代结束时进行修复等）。

2）似乎并没有强调代码的良好“技术”，如缺乏TDD和单元测试。在迭代开发环境中，您需要在单元和集成/验收级别上都具有相当强大的一组自动化测试，以确保在较早的迭代中构建并正常工作的东西不会被较晚的迭代中的工作破坏。 。如果此测试不是自动化的，则在每次迭代结束时所需的回归测试量会越来越大，直到它接管了整个迭代，并且无法完成任何工作。作为测试人员，您在每次迭代中都需要足够的时间来生成自动验收测试，这些测试可以构成回归套件的一部分，以供后续迭代中使用。

3）（从某种意义上说，是＃2的延续）在排序迭代中，至关重要的是预先建立质量，因为在迭代期间没有足够的时间尝试和“测试质量”。我强烈认为，开发人员必须进行某种“测试优先”的实践，才能长期成功。我知道没有其他实践可以对降低缺陷率产生太大影响。最好使用BDD / ATDD（两个词几乎代表同一事物，但有一些细微差别），否则为TDD。 * DD的所有都是设计/开发实践，旨在帮助开发人员在编写代码之前先查看测试所表达的要求行为，从而更好地了解开发人员将要编写的代码。进行单元测试时，它们不是测试活动，尽管名称中有“ test”的名称，但是单元测试是开发人员的责任。

4）他们还没有真正地将测试集成到团队中，并且在迭代结束时基本上仍在“把东西扔在篱笆上”，这意味着您基本上仍在单独的筒仓中工作，而不是一个团队的所有部分。您需要在开发人员认为故事可行后立即对其进行测试，而不是在完成冲刺之后进行测试。

5）如果您在团队中没有任何人接受任何与Scrum相关的培训（或在高性能团队中有过经验）的情况下进行Scrum，那么这是失败的秘诀，请管理层投资于至少要对您的SM进行ScrumMaster培训，我也强烈建议对PO进行产品负责人培训。

6）为此，团队中的每个人都必须清楚测试如何适应事物我建议团队中的每个人都被要求阅读两本非常好的书，其中涉及这本书
a）Crispin＆Gregory的敏捷测试
b）弥补Gojko Adzic的沟通鸿沟

7）在社区方面，我强烈建议您查看Skills Matter网站上的“敏捷测试”部分，在“播客”部分中有大量免费资源。同样，Linked-In的敏捷测试小组也是与其他敏捷测试人员交谈的好地方。

#2 楼

在敏捷环境中，测试人员和开发人员之间的区别变得模糊。测试人员不是唯一的责任，甚至不是质量的主要所有者。质量是整个团队的共同责任。敏捷团队中的个人可能会专门担任特定角色，但根据具体情况将扮演不同的角色。如果测试人员无法深入阅读代码或对设计决策有不舒服的影响，则可能需要进行一些培训（或与DEV配对）以适应敏捷团队。测试是一项关键活动，应包括测试人员，开发人员和客户代表。测试人员不应孤立地完成此操作。开发人员在开始编码之前需要编写自动化的单元测试。这种在编码之前进行测试的方法称为测试驱动开发。
变革是敏捷项目的核心。当产品发生更改时，可能希望测试团队遵循计划。该计划应支持更改。实施变更后，测试人员需要测试变更的未触及区域，以确保产品的持续稳定性。
对话和共同的理解将取代笨重的文档。测试人员应该能够从多个角度看待全局，并提出开发人员和客户可能想到的好问题。
敏捷的测试心态就是与客户合作，查看全局，提供并获得反馈。测试人员在这里与客户紧密合作。与客户紧密合作比成为客户代理更受青睐。测试人员不仅根据协商的工作清单执行任务，而且还与客户进行迭代协作。测试人员在团队会议和错误报告中陈述用户的观点。如果质量不能保护/捍卫客户，则测试人员甚至无法通过发布。
测试人员需要保持警惕，以注意刚性过程对质量的任何影响。长期以来，测试的重点是短视性的，侧重于功能的正确性而不是对人的价值。测试中的这个问题是刚性过程到位的更大问题的一部分。例如，在XYZ公司中，如果测试人员记录的缺陷缺乏需求规范文档的支持，则根据该过程，该问题被视为非问题。在这种情况下，如果确实属于高风险领域，则需要通过与开发人员的共享对话以及管理层的大力支持来对问题进行仔细的风险评估。

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

#3 楼

使用您的测试技能来帮助团队更具体地定义每个故事。这会将您的贡献从严格地发现问题中的一种转变为有助于防止问题发生的一种。每个功能。使用您完善的边界探测和歧义检测技能来提出“您的意思”问题，并提出“假设条件”。帮助团队表达他们对具体书面示例的日益增长的理解。但是，即使您做不到，他们也可以帮助整个团队更好地理解功能，测试他们自己对功能的理解并在迭代过程中标记进度，因为系统满足了越来越多的示例。

#4 楼

在此软件开发环境中，测试应随开发而进行。


随着功能的规划，您应该获得边界。
随着功能的实施，您应该使场景形成边界。功能已经完成，或者至少可以正常工作，您应该在运行方案；

单元测试部分应该由程序员来完成，因为他们不应该为测试人员提供甚至无法运行的代码。

如果您的公司采用了一种更加“牛仔式”的编程方法，并且只是让程序员基于松散的概念来实现某些事情，因此您应该与程序员开会，以找到他们打算使用的界限。

#5 楼

我有时在《敏捷记录》杂志上写过一篇文章（经验教训是在敏捷测试中学到的），着重强调了一些痛点以及我们在过渡到敏捷时所学到的知识。链接在这里。希望对您有帮助

http://agilerecord.com/agilerecord_04.pdf（第73 – 76页）

#6 楼

敏捷pethods的核心测试实践是自动测试，以便始终拥有可交付的软件，并在对功能进行编码之前编写这些测试。这些都是来自XP和TDD的实践。 >

#7 楼

我建议您首先需要向团队提出全面的QE方法，以便他们可以了解它如何与敏捷开发相适应。

对我来说，全面的QE方法基本上意味着全面的测试方法。为此，我从以下四个象限开始：

Integrated  |  Performance
--------------------------
Unit        |  Exploratory

您需要确保基本代码按预期（单元测试），它与数据存储库和其他依赖项正确集成（集成测试），合理执行（性能）。最后，您希望人们研究一切如何协同工作以实现所需的业务目标（探索性）。 “实地”框架。我还谈到了测试人员/量化宽松人员的测试比率（如果分开细分）。如果有1位测试人员和4位开发人员进行测试，而某些票证所需的测试时间是普通测试方案的两倍，那么这将是一个固有的问题。布置完这些之后，我然后提出解决方案：我们是一个团队，每个人都在进行测试。开发人员应该已经熟悉了价值和对单元测试的需求，因此，它只是基于此。

对于您来说，从何处/如何/何时开始进行质量检查（测试团队），如果团队正在从瀑布式过渡到敏捷，则效率更高：

对于开发人员的单元测试

编写代码的单元测试是当前软件开发的基础。 20年前对我来说，它不存在，但现在只是一个基本要求。这不仅仅是“一种很好的实践”，而且是确保软件继续运行的公认基本方法。
因此，如果人们现在不进行单元测试，那么是时候采取更多行动，而不仅仅是电子邮件或午餐和学习。人们需要重新训练。它可以是现场的，也可以是场外的，但是我们在这里要讨论的是几周和几个月，而不是几小时和几天。新员工可能需要雇用。现有的人们可能需要学习如何在体验的价值与继续学习和改变的需求之间取得平衡。我是。

用于开发人员和QA的集成UI测试

以在哪里，如何以及何时进行QA测试为通用主题来驱动更改，以强调接近生产-瀑布的特征-根据敏捷开发的要求，将其作为开发的一部分进行测试。

位置：


开始生产
进行测试阶段
进行本地测试

如何：


首先手动进行质量检查，以了解域和工作流程，并了解所有现有的错误或“功能”。
然后使用脚本和gui IDE工具转向简单的UI自动化。
然后转到使用Web驱动程序的编程解决方案
，然后扩展到使用物理设备和远程服务的多设备和浏览器测试。

时间： >
首先测试当前的产品
还测试即将发布的代码的暂存环境
也要在合并到主请求之前对Pull Requests进行测试
也要进行测试在开发开始之前进行测试以及开发和计划测试