你好 我的名字叫Alyona Isakova，我是Avito的首席测试员，我想向您介绍我将敏捷测试引入团队的经验。 当我阅读有关俄语的敏捷测试和ATDD的文章时，给我的印象是我“不是时尚”，“不是关于敏捷”。 似乎这是一种复杂的结构，需要开发人员的参与，在应用它之前，我仍然必须“耕种”。
我有一段时间坚持这一想法，在设定任务期间写下了任务清单，收集了“功能团队”的会议，并邀请PM，QA，Frontend和Backend在实施之前讨论任务的细微差别。
那些了解他们在说什么的人已经注意到了这个陷阱，不是吗？
如果您搜索的是“敏捷测试”，则可以提出有关课程的建议，几篇文章，并对Wikipedia的方法和定义发表看法：
“敏捷测试是一种遵循敏捷软件开发原理的软件测试实践。 敏捷测试涉及跨职能敏捷团队的所有成员，测试人员贡献了特殊的专业知识，以确保以可持续的速度定期提供客户期望的业务价值。 通过示例说明来捕获期望和不期望行为的示例，并指导编码。”
我不认识你，但是我第一次没有读到这个定义，我被渴望所困扰。 实际上，一切都不是那么干。 最重要的是，敏捷测试就是这种测试过程的方法，与瀑布式方法不同，测试人员在任务的第一阶段更多地参与其中，而在任务的第一阶段则更少（或完全不参加）。
我们的任务流程如何安排
值得一提的是，我们的团队最初使用的是严格的SCRUM，对此表示歉意，这显然与敏捷测试非常吻合，您可以说它暗示了这一点。
1.来自客户的声明（假设PM）
在这一阶段，根据用户故事，验收标准，用例的方案为我们解决了问题。 这样的声明（显然是敏捷）并非偶然-这是我所在部门的同事的优点，她已经在其团队中引入了敏捷测试。 为什么我不能只借用相邻团队的经验，我将在本文后面告诉您。
2.测试人员检查问题陈述
在此阶段，检查任务的唯一性，一致性和有用性。 就我而言，我还在此处添加了“测试”项，该项描述了其他测试用例（例如，否定），这些用例格式不适合编写。 那时，我还不完全了解如何使用验收标准，因此我只是想为开发人员提供最大的输入，以供将来进行检查。
3.所有感兴趣的人或“功能团队”讨论任务
该阶段根据需要进行。 如果经过审查，测试人员认为任务很明确并且不需要其他讨论，则我们进入第四段。
如果需要该阶段，则在会议上将需求和其他工作弄清楚。 通常，任务被分解，在前端和后端的独立操作期间讨论了测试条件。
4.计划，执行，部署积压的任务，并带来了好处和幸福
似乎一切都还不错，但是还有一些需要改进的地方：至少您可以删除几个额外的步骤，因为我们不知道为什么要这么做。
做了哪些改进
感觉到了不断提高的渴望，我和开发人员通过了内部敏捷测试大师班。 事实证明，为了完全遵守该方法，团队只需要更改术语并稍微拧紧我们定制自行车的螺丝即可。
引入这种方法并观察它已经存在的团队是不够的，您需要知识的基础和认识的阶段，在我的情况下，这是由大师班提供的。 我们在开发人员那里接受了培训，这是一个巨大的优势，我强烈建议所有人，这是很难高估他的帮助的。 你们两个（测试人员和开发人员）是开始实施该方法的必要和足够的最低限度。 此外，每个团队和产品都是个体的，为了自己改进此方法，您至少必须尝试一下。
例如，在附近的团队中，在单元测试的有用使用方面具有经验，并在用于存储测试用例和后续自动化的工具中具有初步描述。 我们的团队决定首先从概念上确定必要的验证，然后将其自动化，然后从代码中自动将案例选择到存储工具中。 您可能有自己的互动方式。
我没有声明没有特殊事件就不可能引入一种方法。 但是您需要花一些时间来理解，激励团队并开始改变。 要做好准备，不是每个人都会立即接受张开双臂花费在任务上的时间的增加，对此我感到很幸运。
该主题的内容
“敏捷测试。 整个团队的培训课程，” Janet Gregory和Lisa Crispin。 该书最近以俄语翻译出版，可在Ozone上找到。
到底发生了什么变化
- 在我们的会议上澄清积压（PBR），我变得像一个烦人的优秀学生，问了所有问题：“如果第三方服务中断，将会发生什么？”，“如果我们返回null而不是0，将会发生什么？”，“ A为什么我们将其称为“而不是那边”？”，“如果我们不获取所有数据怎么办？”，“如果地球被反叛的恐龙捕获了怎么办？” 只是在开玩笑，只有重要的问题，没有“ null”和“ 0”。
随着时间的流逝，这些家伙意识到在这样的讨论中，已经诞生了一些事先无法解释的案例，他们现在可以预见。 以前，诸如“如果一切都崩溃了该怎么办？”之类的问题。 我想知道是在测试阶段，还是现在在设置阶段。 - 代替任务中的“测试”项，我们详细而有意识地编写“接受标准”，并确定将来的自动测试的数量和级别。
诚实地说，值得一提的是，并非100％的情况下我们都预先知道自动测试的级别。 有时候，我们在技术上无法做到这一点，或者比我们在会议上花费的时间更长。 在实践中，通常不可能采取重大行动。 这是允许的-随着时间的流逝会出现一些事情。 - 我们目前不执行项目“测试人员对问题陈述的审查”和“功能团队”。 我们已经在PBR会议上解决了所有问题，因为所有必要的人员已经在这里，并且在此过程中讨论了接受标准。
- 将测试人员添加到单元测试检查代码中，以确认是否有足够的检查。
- 在开发过程的最后，运行自动测试（在所有级别上），而不是通常的功能测试，并且仅执行研究测试。
理想情况下，当然完全不应该进行测试，但是在我们的实践中，我们发现，当您对许多团队开发的产品进行更改时，添加研究测试会更容易，更正确。
您遇到了什么困难？
1.什么是单元测试
我们面临这样一个事实，我们的质量检查人员不了解正在测试的单元测试，因此不信任它们。为了保持警惕，我们编写了更高级别的测试，并用heel脚的脚跟说：“自动化，您不能宽容”。
根据决定：
我们和受过敏捷教育的开发人员（感谢他和他的耐心）一起坐在角落里，一个小时，他在手指上向我解释了什么是单元测试，与他们一起吃的东西以及为什么他们还不能检查“这东西”。 由于我们的痛苦，诞生了一个了不起的服务方案：他们以自己理解的方式来制定它。
一个选定的箭头-一次旅行-一次单元测试中的检查
结果，几个月后，我自己编写了一些单元测试，并删除了较高级别的多余检查。 当然，这主要是复制粘贴，但是有意识！
也许您已经很好地理解了单元测试的本质，并且不必花时间在此项目上，但是如果没有，请在一个安静的环境中给开发人员提供补贴，并向他提出问题。
2.在当前的实现中，并非所有的测试都可以不做任何修改而省略
根据决定：
通过增加单元测试的数量，删除了e2e测试的不必要数据集。
我们已经修改了已经实施的单元测试，我们写下了想要从中进行哪些检查。 在那之后，很出乎意料的是，事实证明我们错过了一些检查。
确定了我们想要什么以及在什么级别上，我们为未来设定了任务。
在对已经存在的内容进行了培训之后，我们开始研究该方法的实际应用，并开始对尚不可用的方法进行检查。 这已经很难了。
结论
这种方法的独特之处在于它是自然的，并且源于“向用户传达价值”，“减少手动质量检查”，“提供覆盖范围”之类的东西。 您将如何精确地执行此操作是另一回事，但是这种方法可以为您提供一些建议，并建议您使用哪些主密钥来简化您的生活，而不丢失任何东西。
例如，“敏捷测试实践”是现成的应用程序工具，“值”和“原理”是健康人的测试人员所理解的，但是仍然值得反复向自己和您的团队说，因为我从经验中知道：在高负载模式下，它们通常会降级为背景。
ATDD方法论的主要内容是，在做某事之前，您需要提出一个完成工作的准则和一个正确完成工作的准则。 粗略地说，该方法确定了您与团队达成一致的时间。 其余的随戏一起进行。
例如，您意识到在您的条件下您无法区分测试的集成层-没关系。 从方法的第一步开始：写下验收标准，定义测试及其水平，为更光明的未来创建任务。 这里最有用的阶段是在设置任务阶段从您的细心问题中预先定义检查-最快的积极结果将向您的团队证明您没有浪费他们的时间。
- 总的来说，敏捷测试方法以及其中提出的价值，原理和实践都遵循很明显的事情，就像我最喜欢的高等代数老师说的那样：“但是这里有必要运用常识。” 这是值得遵循的，不仅是在测试中。
有一次，在讨论中，我和团队意识到我们在太多条件下进行检查，这使我们想到了一个问题：“我们是否恰好在该参数上调用该方法？” 事实证明，可以通过调用本质本身而不是本质上的逻辑来从根本上简化问题的表述。 也就是说，条件是当我们有一个从属实体，但是没有实体本身，它就不存在。 它使我们的生活更轻松。
通过如何确定测试用例的级别，这是一个单独的holivar，当您开始感到疼痛时，请尝试参考文献。 请记住，必须将实践应用于真正解决问题的地方，使生活更轻松。 一切顺利，祝你好运和海豹！