利用自动化实现敏捷的软件测试
多年来，我一直与处于不同敏捷成熟度的团队合作。有些是完全陌生的团队，有些是 "做 "敏捷的团队（说说而已），还有极少数是敏捷的团队（走走而已）。无论一个团队的敏捷成熟度如何，几乎都有一个共同点：QA要努力跟上敏捷软件开发的快节奏。
当团队正在学习如何以敏捷的方式运作时，他们会看到事情发展得有多快。这是敏捷的一大好处，但它也伴随着一些假设，如果忽略了这些假设，就会导致团队在频繁交付产品的迭代中挣扎。
我认为自动化测试是一个团队真正体验敏捷的好处的不言而喻的必要条件。一个团队只有在工具、管道和流程的支持下才能走得更快。
让我们来谈谈团队可以采取的方法，以提高他们的自动化测试水平。
测试自动化工具和框架的领域可能会让人感到不知所措。每个团队都有不同的需求，所以从头开始建立一个自动化解决方案可能是一项艰巨的任务。
即使是已经建立了自动化套件的团队，也会不断发现新的框架和自动化趋势，以便在这个空间里跟随（一体化的自动化解决方案，可视化UI回归工具，以及Selenium替代品--仅举几例！）。
也就是说，一般来说，有类似的方法来提高团队的自动化水平，这取决于团队的当前状态。
以真正的敏捷方式，我们将确定一些团队角色，这些角色需要独特的定制解决方案来成为自动化的超级明星。
- 角色1： 团队没有自动化测试；所有的测试活动都是以手工方式进行的。
- 角色2： 团队有自动化测试，但自动化没有给团队带来好处。
- 角色3： 团队有自动化测试；自动化提供价值，并作为团队的推动者。这对每个人来说都是不同的!
现在，让我们深入研究这些类型的团队，并确定如何帮助他们在自动化旅程中取得成功。
角色1：如果你的团队还没有自动化，如何开始？
确定团队的技能组合
QA团队有不同的构成。有些是100%的手动测试人员。有些是100%的开发人员，可能是零测试经验。其他的则是手动和技术测试经验的结合。
当与现有的团队合作时，了解你的团队的背景和技能组合是很重要的，这样他们的优势和技能就能以最好的方式被利用。
如果一个现有团队的QA成员仅仅是没有技术背景的手动测试人员，他们需要一个与开发人员或SDET（软件开发测试工程师）不同的自动化介绍。
他们可能对编码感兴趣，因此在深入了解自动化之前，应该给予适当的编程培训。这将确保他们的长期成功。
另一方面，手动测试员可能不想编码，但仍然可以对自动化测试活动作出贡献。在这种情况下，团队可能要考虑使用BDD（行为驱动开发）框架（如Cucumber）来实现自动化，以便非技术团队成员可以参与进来，帮助编写测试方案。
自动化应该被用来提高手工测试的效率
例子包括在手动测试API时使用Postman的测试脚本，像LambdaTest这样的可扩展的跨浏览器测试工具，创建JavaScript书签以方便填写表格，或自定义bashing脚本以生成测试数据。自动化工程师和开发人员可以以创造性的方式利用自动化来加速人工测试
对于一个由人工和技术测试人员组成的团队，我强烈建议使用配对编程的理念，与团队中具有互补技能的人合作。
如果你有一个拥有大量领域知识但没有编码背景的人和另一个拥有强大的技术能力但不那么专业的人，这两个人可以成为一个非常强大的搭档
在任何情况下，团队在为他们的自动化解决方案打下基础时必须清点他们的技能。一旦确定了这一点，在跳入自动化之前还有其他因素需要考虑。
有太多的因素可以列出（而且可能因团队或项目的不同而不同），但这里有几个常见的因素：
- 技术栈。 如果技术团队成员只用JavaScript编程，你很可能不会选择一个Python特定的自动化框架。
- 技术技能组合。 如果非技术团队成员想为自动化测试作出贡献，可以考虑行为驱动开发（BDD）自动化解决方案。
- 应用功能。移动应用？网络应用？API？什么都有框架!
- 理解你要自动化的东西。布置测试场景，确定应用程序的关键功能，用户流 - 这可以帮助你选择最适合的测试自动化工具。例如，如果你的应用程序有图形、图表、复杂的图表等，这些都是关键的功能，你可以考虑支持可视化UI测试的解决方案。
这里的关键是在跳入之前，要花时间来规划解决方案。让开发人员和技术负责人参与进来是有益的。
一旦团队做好了基础工作，你就可以开始自动化了。我强烈建议在你开始之前熟悉测试自动化金字塔的概念。下面我将介绍一些反模式和不应该做的事情。
角色2：纠正路线，使你的自动化测试走上正轨
不幸的是，对于团队来说，从一开始就没有采取有计划的方法就把自动化测试解决方案扔在一起是非常普遍的。结果是，测试人员最终在一个不可维护的套件中得到不可靠的测试。
在我自己的经验中，我曾加入过一些团队，他们在一个自动化框架上投入了两年或更多的时间，但却发现它不能满足他们的需求，于是就把整个框架废除了，换了一个新的框架。
虽然我赞成用新的、闪亮的、能使你更有效地工作的工具集来替换，但没有人愿意抛弃多年的努力工作。
如果这些痛点听起来很熟悉，可能是时候看看你如何能改善你的自动化了：
- 测试需要很长的时间来执行（几个小时或更长）。
- 你的回归测试是在测试人员的本地机器上运行。
- 测试经常失败，原因不明。
- 没有简单的方法来运行全部测试套件的子集。
- 测试人员花了很多时间来更新测试，当应用程序中的用户界面发生变化时，测试就会失效。
- 你的回归套件有数以百计的UI、端到端、和基于用户故事的测试。
- 测试运行是不可靠的，有假阳性/假失败。
我至少经历过一次这样的情况!虽然所有这些都会给测试人员带来很大的痛苦，但也有解决办法。对于敏捷团队来说，一切都进展迅速。然而，我看到团队面临的最常见的问题是时间。你如何平衡自动化工作和所有其他的日常活动？
证明自动化的潜力
如果QA很难让产品拥有者/BAs/领导层分配时间给自动化，向他们展示一个概念证明或演示，说明自动化可以节省多少时间。
自动化测试为QA创造了更多的时间来测试，只有人类才能向开发者提供更快的反馈，并在回归过程中节省时间。所有这些都相当于更快地交付功能。
确保对自动化测试有可见性
整个开发团队（QA、开发人员、产品拥有者）应该对产品的质量感到某种程度的所有权 - 包括自动化测试。
我发现获得产品负责人对关键用户场景的意见是非常有价值的，然后我将其转化为针对每个拉动请求运行的自动化烟雾测试，使整个团队对最重要的功能部分始终处于工作状态更有信心。
在创建一些自动化测试时，我发现了两个错误。
自动化测试没有发现这些错误。这些bug是作为自动化测试开发过程中的副产品被发现的。
自动化是作为#测试的一部分而使用的不同镜头
- Brendan Connolly（@theBConnolly）2021年6月24日
当团队知道什么测试在运行时，他们会在新功能开发过程中插话，并确保有时间来自动化新的测试!自动化和测试工作也应该包括在一个故事的 "完成定义 "中。另一个关注自动化的好方法是在Sprint Review中演示框架的改进或测试的运行。
让它变得有用
我见过一些团队为一个巨大的自动化套件投入了数百个小时，但只是每月运行一次。自动化是一项时间投资，只有当它被有效利用时才会有回报。
理想情况下，你有针对每个拉动请求运行的自动化测试--即使这只是烟雾测试的一个小子集。使用CI/CD工具使你能够安排每晚的回归运行，根据代码合并触发执行，以及更多。
角色3：你的自动化很好--如何让它变得更好
即使是最令人印象深刻的测试套件，也总是可以被改进的！在拥有成熟的自动化设置的团队中，你会发现你的测试套件是最棒的。在拥有成熟的自动化设置的团队中，我喜欢和他们一起处理以下几件事：
- 清理规范文件，集中精力提高整个自动化框架的可维护性。
- 识别任何薄弱环节并使其更加可靠--每一个测试套件都有一些薄弱点
- 寻找机会，通过利用API调用或数据库交互，使测试更接近于应用程序代码，从而摆脱脆弱的UI测试的步骤。
- 如果QA团队由专门的自动化工程师和专门的手动测试人员组成，混合这些角色，以便在测试过程中不存在瓶颈问题。
- 使用LambdaTest等工具并行运行测试（对共享测试环境、测试账户或测试数据持谨慎态度），以成倍地加快回归执行速度。
不断地将时间用于自动化
不要让自动化成为 "设置和遗忘"。如果团队不积极维护，自动化会很快变得过时和陈旧。在开发新功能时，仔细研究如何确保测试覆盖率，同时保持测试套件的可维护性。
将测试转移到左边
针对每一个PR，每一个合并请求，以及每一个发布版本的构建，运行自动化测试。在开发周期中，问题越早被发现，修复的成本就越低。
总是探索新事物
你听说过合同测试吗？视觉UI测试呢？自动化工具和框架在不断发展，为我们带来了前所未有的创新方法来加快测试速度。作为工程师，我们应该利用它们来解决问题，以改善我们的团队。
总结!
在敏捷团队中，拥有某种形式的自动化测试是至关重要的。没有它，测试不可避免地成为快速交付功能的瓶颈。人工测试在确保软件为人类提供良好功能方面总是有其位置。没有任何工具或软件会完美地取代或复制人类的眼睛和批判性思维，而这正是测试人员心理的宝贵组成部分。我向你提出挑战，要对你的测试的现有极限进行边界测试，并将你的软件的质量保证提高到新的水平。你的团队会为此感谢你的
